finance-mcp-server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have distinct purposes, but several overlaps create ambiguity: multiple connection/credential checks (dart_test_connection, check_dart_api_key, finance_test_connection), two company-profile tools (get_company_profile vs get_company_profile_by_query), and two financial-statement tools (get_financial_statements vs get_full_financial_statement). Detailed descriptions help, but an agent could easily pick the wrong one based on name alone.
Naming Consistency4/5
Most tools follow a readable get_/search_/check_/place_/cancel_/modify_ pattern, but there are minor inconsistencies: connection checks mix test_connection, check_*_api_key, and check_*_credentials; get_financial_statements vs get_full_financial_statement uses awkward singular/plural variation; Telegram tools use list_dialogs instead of get_dialogs.
Tool Count2/5
46 tools is far beyond the 3-15 well-scoped range, and the count is inflated by redundant health-check/credential tools and by bundling three unrelated integrations (DART, Toss, Telegram) into one server. It is not an extreme 50+ count, but it is too heavy for a coherent single-purpose surface.
Completeness4/5
Within each bundled domain, coverage is reasonably complete: DART covers company search, financials, shareholder data, and disclosures; Toss covers quotes, orders, and accounts; Telegram covers listing chats, reading/searching messages, and downloading files. Minor gaps like no send_message and no broader historical order report exist, but agents can work around them.
Average 4.1/5 across 46 of 46 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only names filters. It does not explain sort order, how cursor/limit pagination works, what status values are valid, whether results are scoped to the required account_seq, or any other observable behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the action and resource front-loaded. It is compact and readable, though 'spec's' is vague filler and the filter list does not exactly match the schema parameter names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters, a required account_seq, and a cursor-based pagination field, the description is incomplete. It does not mention the mandatory account_seq, pagination behavior, how dates should be formatted, or how this endpoint relates to get_order. The output schema may cover return values, but the input behavior is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add some meaning by identifying status, symbol, from, to, cursor, and limit as filters, but 'from'/'to' do not exactly match from_date/to_date, account_seq is omitted entirely despite being required, and no value formats or status options are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('orders'), and lists the filter dimensions, so it is immediately clear this is the plural listing endpoint and can be distinguished from the singular get_order. The phrase 'spec's' is somewhat obscure, but the core purpose is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use get_orders versus related siblings like get_order, get_holdings, or get_recent_trades. Use is only implied by the command 'List orders', with no exclusions, prerequisites, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the tool returns a message and verifies the process is working, but does not say whether a network request is made, whether credentials are required, what failure behavior looks like, or what the required 'message' parameter does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, and the core action is front-loaded. It is appropriately sized for the simplicity of a health-check tool, though brevity comes at the cost of parameter clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the description is incomplete for reliable invocation: the required parameter is unexplained, usage guidance versus sibling test tools is missing, and there is no indication of what the returned message will contain or validate. The output schema exists but does not compensate for the missing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the required 'message' parameter. It does not; the mention of 'Return a message' refers to the output, not the input meaning. The parameter remains ambiguous: is it echoed, sent to a server, or simply a required arbitrary string?
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Return a message') and its purpose ('verify that the MCP server process is working'). It is specific enough to distinguish from credential-check tools like check_toss_api_credentials, though it does not explicitly differentiate among the several test_connection sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus check_toss_api_credentials, dart_test_connection, telegram_test_connection, or finance_test_connection. Since multiple near-sibling test and credential-check tools exist, explicit usage conditions or exclusions would be valuable but are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It only adds that cancellation does not require confirmation, but it omits important behavioral details such as whether the operation is idempotent, what happens to an invalid order state, and whether the cancellation is immediately irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It states the operation first and then adds a relevant behavioral caveat about confirmation, making every word useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter cancellation tool with an output schema, the description is minimally adequate: the purpose is clear and the required parameters are present in the schema. However, it leaves the agent to infer usage boundaries, invalid-state behavior, and side effects, so it is complete enough to invoke but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain account_seq or order_id. The parameter names provide some surface-level meaning, but the meaning of account_seq, its integer-or-string union, and its relationship to the order remain undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Cancel' and names the resource 'pending live order', making the operation immediately clear. It also differentiates the tool from siblings like place_order, modify_order, and get_order by stating exactly what action it performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance. The phrase 'pending live order' implies a state constraint, but the description does not mention alternatives such as modify_order for adjustments, nor does it clarify what happens if the order is already filled or cancelled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the source (Open DART) but does not state whether authentication is required, how fresh the data is, whether it is read-only, or if there are rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and immediately states the tool's purpose, then follows with a clear parameter breakdown and a useful example. Every sentence earns its place without redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the invocation details are mostly sufficient. However, the description omits when to use this tool instead of get_company_profile_by_query, and does not mention any prerequisite like an Open DART API key, which is a notable gap given the sibling tools include check_dart_api_key.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and type with 0% coverage, but the description compensates well by explaining that corp_code is an eight-digit Open DART corporation code and giving a concrete example (Samsung Electronics is 00126380). This gives the agent enough context to supply the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves official company information from Open DART, with a specific verb and resource. However, it does not explicitly distinguish itself from the sibling get_company_profile_by_query, which likely serves a similar purpose via different lookup criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_company or get_company_profile_by_query. It only explains the required corp_code argument, with no mention of preferred scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. 'Get' clearly indicates a read operation, and 'all available details' plus 'execution information' gives some sense of scope. However, it does not explain any prerequisites, edge cases, or what happens when the order is not found or when account_seq is mismatched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. 'Get all available details' immediately states the action and scope, and 'including execution information' earns its place by adding useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and covers return values, the description omits key context needed for correct invocation: what account_seq means, how the two parameters interact, and how this tool differs from get_orders. With no annotations and minimal schema descriptions, the definition leaves material gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate by explaining the two required parameters. It only weakly implies order_id through 'one order' and never explains account_seq or how account_seq relates to the order lookup. The agent is left to infer the parameter semantics from names and types alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get ... one order') and adds 'including execution information,' which clarifies what details are returned. It does not explicitly name sibling tools, but the singular 'one order' helps differentiate it from list-style tools like get_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one order' implies this is for fetching a single order's full details, distinct from get_orders or place_order. However, there is no explicit when-to-use guidance, exclusions, or mention of alternatives such as using get_orders for collection-level queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It does flag that the order is 'live,' but it does not warn that submitting can execute immediately, commit funds, or require confirmation for high-value orders, despite listing confirmHighValueOrder as a wire field. This is thin coverage for a real-money mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose, and the second adds the most decision-relevant parameter constraints. The wire-field list is slightly redundant with the schema, but it provides useful camelCase mapping and does not add fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter, high-stakes order submission tool with no annotations and no schema descriptions, the description leaves meaningful gaps: valid values for side/order_type/time_in_force, the semantics of confirm, and the behavior after submission are absent. An output schema exists, so return-value documentation is not required, but the invocation requirements are incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 11 parameters, so this dimension depends heavily on the description. The description adds two useful facts—quantity and orderAmount are mutually exclusive, and orderAmount is only for US MARKET orders—but it leaves side, order_type, time_in_force, price, confirm, and client_order_id semantics to the agent's assumptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Submit a live quantity- or amount-based stock order,' giving a specific action and resource. This clearly distinguishes place_order from sibling order-management tools like cancel_order, modify_order, and get_order(s), which serve different verbs on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose as the new-order entry point is implied by 'Submit a live... order,' but the description never explicitly contrasts it with modify_order/cancel_order or states conditions like 'use modify_order for existing orders.' It does provide context that amount-based orders are restricted to US MARKET orders, which helps select the right invocation mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently states the tool returns a message and implies a read-only health-check behavior. However, it does not clarify whether it performs an external network call, what the returned message looks like, or how failures are reported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the core action and purpose. Every word earns its place, with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial health-check tool, the description is mostly adequate, but it leaves the required parameter unexplained and gives no routing guidance among the many sibling test_connection tools. The presence of an output schema partially compensates, but the missing parameter semantics is noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 the 'message' parameter at all. It is unclear whether the parameter is echoed back, used as a test payload, or required only as a formality, leaving the agent to guess what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns a message to verify the MCP server is working. While it doesn't explicitly differentiate itself from sibling test_connection tools, the name 'dart_test_connection' plus the 'verify server working' phrasing makes the intent clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to verify the MCP server is operational, which provides basic contextual guidance. However, it does not mention when to use this tool versus alternatives like check_dart_api_key or other test_connection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Look up' implies a read-only operation, but the description does not disclose error behavior for invalid symbols, whether prefixed symbols are rejected or stripped, rate limits, authentication needs, or data freshness. Transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, then a clearly formatted Args block. Every sentence earns its place, and the key input constraints are easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with an output schema, the description provides a solid invocation contract: what the tool returns at a high level, how to format symbols, the maximum count, and the no-prefix rule. It lacks usage alternatives and behavioral caveats, but the core information needed to call the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully documents the sole parameter: comma-separated symbols, up to 200, no market prefix, with concrete examples. This adds essential meaning beyond the bare string schema and is sufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Look up') and resource ('basic info... for symbols') and enumerates the kind of data returned: name, market, currency, status, shares outstanding. The field list and KRX/AAPL examples make the tool's scope distinguishable from pricing or financial-statement siblings, though it does not explicitly name an alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings like get_company_profile, get_current_price, or search_company. There are no exclusions, conditions, or alternative-tool pointers. The 'Args' block explains input format but does not help an agent select between similar-looking tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does disclose the filtering behavior: chat_type filters to all, channel, group (including supergroups), or user. However, it does not mention pagination, ordering, authentication, or other runtime behavior, leaving a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the verb-resource statement is front-loaded and the parameter detail follows directly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation with an output schema, the description covers both the operation and filter semantics adequately. A small gap remains in not mentioning when to prefer this over sibling message/channel tools, but the low complexity and existing output schema keep it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates for the single parameter by enumerating the accepted chat_type values and clarifying that "group" includes supergroups. This is exactly the semantic guidance the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb-resource pair "List Telegram dialogs", which clearly identifies what the tool does. It does not explicitly compare itself to siblings like get_messages or get_channel_info, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by "List Telegram dialogs" and the chat_type filtering sentence, but no when-to-use or when-not-to-use guidance is provided. The agent must infer that this is the right tool for enumerating dialogs rather than messages or channel info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral disclosure. It clarifies that listed_only filters to companies with a stock code and that limit caps results, which adds behavioral context beyond the schema. However, it does not mention read-only status, error behavior, or other operational traits, though 'Search' implies a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence summary followed by clearly labeled parameter explanations. There is no redundant content or restating of schema fields beyond what adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with an output schema and three parameters, the description provides enough information to invoke it correctly. It could be more complete by distinguishing itself from get_company_profile_by_query and noting whether the result is a list or a single profile, but the output schema likely covers return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains the query format with Korean examples, defines listed_only as filtering to stock-code-bearing companies, and specifies the valid range for limit (1–50), which the schema omits. Every parameter receives meaningful, actionable semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search DART companies by company name, stock code, or corp code.' This is a specific verb and resource with concrete query types. It does not explicitly differentiate from sibling tools like get_company_profile_by_query, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need to find DART companies using a name or code, but it does not explicitly state when to prefer it over alternatives such as get_company_profile_by_query or search_disclosures. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It communicates that this is a read-style 'Get' operation and that only one symbol is accepted, but it does not disclose depth of the order book, data freshness, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a tightly scoped Args block. The Korean parenthetical is minor redundancy but does not meaningfully hurt readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema available, this description covers what the agent needs to invoke it correctly. It does not discuss return structure in prose, but the output schema covers that, so this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates for the single 'symbol' parameter by explaining the ticker format, the lack of a market prefix, giving concrete KRX and US examples, and emphasizing the one-symbol-per-call rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get'), a specific resource ('current bid/ask order book'), and a clear scope ('for a single symbol'). This is immediately distinguishable from sibling tools like get_current_price or get_candles based on the resource alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when an order book snapshot for one symbol is needed, but it does not explicitly state when not to use it or mention alternative tools. It does provide useful invocation constraints like one symbol per call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It communicates a read-only 'Get' action and the 'today's' temporal scope, which is helpful. But it does not disclose auth requirements, error behavior, or data-source details, leaving some room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The Args block is compact. The Korean parenthetical is mildly redundant for an English interface but does not hurt clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query tool with an output schema, the description is nearly complete: it gives the query scope, symbol format, and a concrete example. It does not explicitly route users away from sibling price tools, but that is not required for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and type, so the description's Args section adds essential meaning: 'single ticker symbol, no market prefix, e.g. 005930.' This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: getting today's upper/lower price limits for a single symbol. The resource, price limits, is distinct from sibling tools like get_current_price and get_orderbook, so an agent can identify what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for a single symbol's daily price limits. However, it does not explicitly compare against alternative tools or state when not to use it. The guidance is useful but mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds useful constraints: no market prefix, accepted count range 1-50, and single-symbol-only behavior. However, it does not explicitly state that this is a read-only operation, describe the response shape, or mention any authentication/rate-limit implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence summary followed by a short Args block. Every sentence adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers both parameters and key invocation constraints, which is adequate for basic use. But because there is no output schema or annotations, it would benefit from a note about the returned trade fields or ordering, and possibly a pointer to sibling tools such as get_current_price or get_orderbook.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides bare property names, so the description compensates well. It explains symbol format with concrete examples ('005930', 'AAPL'), states that no market prefix is used, emphasizes one-symbol limit, and defines count as between 1 and 50. This is genuinely useful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action and resource: 'Get the most recent executed trades (체결) for a single symbol.' This distinguishes it from siblings like get_current_price or get_orderbook by the data type, though it does not explicitly name any alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence and parameter notes provide clear context for when to use the tool: when recent executed trades for a single symbol are needed. It also states the constraint that only one symbol is accepted per call. However, it does not mention any sibling alternatives or exclusions such as 'use get_orderbook instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It explicitly states that the key is not exposed, which is an important safety guarantee for a diagnostic tool. It does not describe exit behavior or logging, but the presence of an output schema covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the action and resource and ends with the security-relevant qualifier, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with an output schema, the description is complete: it tells the agent what is checked and guarantees the key is not revealed. No additional invocation context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics to clarify. The zero-parameter baseline of 4 applies, and the description does not need to compensate for missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Check whether the DART API key was loaded') and adds a meaningful security qualifier ('without exposing it'). This clearly distinguishes it from sibling tools like dart_test_connection and check_toss_api_credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives such as dart_test_connection, nor any mention of prerequisites or recommended call order. The intended context is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. 'Find ... and return' clearly indicates a read-only retrieval operation, and the word 'Exact' communicates strict matching rather than fuzzy search. It does not discuss rate limits or error behavior, but for a simple lookup tool the behavior is adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the tool's purpose, and contains no filler. The Args section adds necessary parameter semantics without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the return value structure is already documented. The single parameter is fully described, and the read-only nature is implied. The only notable omission is guidance on when to prefer sibling tools like search_company for less exact queries, but this is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare string property named 'query' with no description, so all semantic weight falls on the description. The description compensates fully by enumerating the three valid query forms: exact company name, six-digit stock code, or eight-digit DART corporation code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pairing: 'Find a listed company and return its DART company profile.' It clearly states what the tool does, though it does not explicitly differentiate itself from the sibling tools search_company or get_company_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent what inputs are accepted ('Exact company name, six-digit stock code, or eight-digit DART corporation code'), which implies the tool is best used when an exact identifier is known. However, it does not name alternatives such as search_company for fuzzy or partial matches, so usage guidance relative to siblings is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the price is the last-traded price and that batch queries up to 200 symbols are supported. However, it does not mention error behavior, return structure, or whether prices are delayed/real-time, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and then gives exactly the parameter details needed. No filler or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter price lookup with an output schema available, the description covers purpose and parameter semantics adequately. It could be slightly more complete by noting expected return value shape or potential errors, but those are partially addressed by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbols' as a string with no description. The tool description fully compensates by specifying comma-separated tickers, a maximum of 200 symbols, no market prefix, and concrete KRX/US examples. This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Get the current (last-traded) price for one or more symbols.' This clearly distinguishes the tool from related siblings like get_recent_trades or get_orderbook by focusing on the current price snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a current price is needed and provides input constraints, but it does not explicitly say when to prefer this over alternatives such as get_candles or get_stock_info. No exclusion rules or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions latest versus historical rates, but does not explain read-only behavior, rate source, limitations, error conditions, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and uses a clear Args structure. Every line adds meaningful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only lookup tool with an output schema present, the description provides enough invocation detail. Minor gaps such as edge-case handling and explicit rate behavior are not critical but keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are no enums, but the description compensates fully. It specifies allowed values for base_currency and quote_currency, and explains that date_time is optional, ISO 8601, and used for historical rates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Get the exchange rate between two currencies.' This is not a tautology and clearly separates the tool from sibling tools, none of which are exchange-rate focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: an agent should use this tool when it needs an exchange rate between KRW and USD. The parameter guidance also distinguishes latest versus historical usage, though it does not explicitly name alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral-disclosure burden. It usefully discloses the Open DART endpoint, consolidated/separate scopes, and report types, but it omits authentication/API-key prerequisites, rate-limit behavior, and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence summary, followed by useful endpoint context and a compact Args list. Every sentence adds information, and the length is justified by the four parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and all parameters documented in the description, the core call is well specified. It would be more complete with an explicit pointer to get_full_financial_statement for full statements and a mention of Open DART API-key requirements, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter: corp_code with an example, start_year/end_year format, and report_type with all allowed values and their meanings. This goes well beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get key financial-statement accounts for a company across a range of years.' It lists the exact figures returned (total assets, liabilities, equity, revenue, operating profit, net income) and explicitly notes both consolidated (CFS) and separate (OFS) statements, which distinguishes it from siblings like get_full_financial_statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the first sentence and the detailed report_type options, but the description never explicitly says when to use this tool instead of alternatives such as get_full_financial_statement. No exclusions or routing guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It names the underlying Open DART endpoint, explains that data covers start and end of each reporting period, and lists the specific shareholder fields returned. This is substantive transparency for a read-only status lookup, though it does not discuss API-key requirements or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by the data source and a clean Args block. Every sentence adds necessary information: the example corp_code is useful, the report_type list is explicit, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the four parameters, no annotations, and an output schema that presumably covers return values, the description is largely complete. It documents all parameters, the data source, the contents of the response semantics, and the supported reporting periods. It only lacks explicit guidance on choosing among sibling shareholder-related tools, but that is secondary to making a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully document parameters, and it does. It explains corp_code as an eight-digit Open DART code with a concrete example, defines start_year and end_year as four-digit business years, and enumerates all report_type values including Korean names and 'all' semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets major/largest-shareholder ownership status (최대주주 현황) across years and describes the data returned: each major shareholder's name, relationship to the company, and share ownership at reporting period boundaries. It is distinct enough from siblings like get_major_shareholder_changes and get_minority_shareholder_status, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: call this when you need major-shareholder ownership status across years, with parameters for year range and report type. However, the description does not explicitly state when to prefer this over related siblings such as get_major_shareholder_changes or get_minority_shareholder_status, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It does disclose the upstream Open DART endpoint and the specific metrics returned, which adds real context. It stops short of covering auth prerequisites, rate limits, error behavior, or data availability constraints, all of which would be useful without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-line purpose, then moves directly into a compact Args block. There is no filler, and every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so explaining the return structure is unnecessary. The description covers the endpoint, all parameters, and the reported data metrics sufficiently for correct invocation. The remaining gap is the lack of explicit sibling routing and behavioral caveats, which are mostly scored elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section fully compensates: it explains corp_code format with an example, specifies four-digit years with examples, and enumerates every report_type value with Korean labels and the meaning of 'all'. This is exactly the information an agent needs to fill the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb ('Get'), a specific resource ('minority/small shareholder status'), and a time dimension ('across years'), reinforced by the Korean term. This makes it immediately distinguishable from the sibling get_major_shareholder_status even without an explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the tool name and first sentence: fetch minority shareholder status data. However, the description never explicitly says when to prefer this tool over get_major_shareholder_status or other shareholder-related siblings, and it offers no alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly states 'read-only', which is valuable safety information, but does not mention authentication requirements, error cases, or whether the value is real-time. This is minimal but meaningful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line summary followed by a clean Args block. Every element earns its place, and the read-only safety cue is included without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with two parameters and an output schema, the description is nearly complete. It covers parameter sourcing, valid currency values, and safety. It stops short of documenting exclusions or alternative tools, but those are not essential for correct invocation here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description is the sole source of parameter meaning. It explains that account_seq is the numeric value returned by get_accounts() and that currency accepts 'KRW' or 'USD', adding real value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get') and a clear resource ('cash buying power for one account'), and distinguishes it from siblings like get_sellable_quantity by focusing on cash buying power. The Korean parenthetical and read-only label reinforce the operation's nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it requires an account_seq returned by get_accounts(), which is a practical dependency. It does not explicitly name alternatives or state when not to use this tool, but the context is enough to guide correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly notes that the operation is read-only, which is a useful behavioral disclosure. However, it does not mention authentication requirements, whether multiple markets are returned in a single call, or any rate-limiting behavior, so the disclosure is somewhat minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main purpose appears first, followed by a short read-only note and a single parameter explanation. Every sentence earns its place, and there is no redundant or promotional language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, an output schema, and a clear source for the required account_seq. The description provides enough context for an agent to call it correctly. It stops short of describing what 'by market' means in practice, but the output schema likely covers the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining that account_seq is the numeric account sequence returned by get_accounts(). This adds practical meaning beyond the raw schema, which only says integer or string. The guidance about where the value comes from is especially valuable for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get your brokerage commission rates by market.' It is unambiguous and differentiates itself from sibling tools because no other sibling targets commission rates. The Korean parenthetical reiterates the read-only nature without confusing the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by instructing that account_seq is 'the numeric accountSeq returned by get_accounts().' This tells the agent the prerequisite call to make before using this tool. It does not explicitly name alternatives or state when not to use it, but the tool's purpose is narrow enough that this is not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden itself. It states that the tool uses an external Open DART endpoint, returns every line item across the balance sheet, income statement, and other statements, and is scoped to a single business year and report type. It does not cover auth or rate limits, but for a read-only financial-data fetch the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-oaded with the core purpose and uses a compact Args block. The phrase 'every line item' appears twice and the endpoint name adds mild redundancy, but it stays under roughly 130 words and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter external-data tool with no schema descriptions and no annotations, this description is largely complete: it covers every parameter, defaults, examples, allowed values, and the nature of the response. The only notable gap is explicit routing guidance between this and the sibling get_financial_statements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schea has no descriptions (0% coverage), but the description fully compensates: it defines corp_code with an example, year format, all four allowed report_type values, and both fs_div values with their defaults. This is exactly the semantic content the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Get the complete financial statement (every line item) for one period.' It further identifies the Open DART full-statement endpoint and explicitly enumerates which statements it covers, making it distinguishable from the tersely named sibling get_financial_statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording 'complete' and 'every line item' implies this is the tool for full financial-statement detail, but it never names alternatives or gives an explicit when-to-use/when-not-to-use rule. No mention of get_financial_statements as the lighter or summary alternative, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'read-only' and scopes behavior to one account, which is useful. However, it does not mention potential errors, authorization requirements, or behavior for invalid account_seq values, leaving some behavioral expectations implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear purpose sentence plus one short parameter explanation. It is front-loaded with the core function and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, the description is largely complete. It covers the action, the account scope, the read-only nature, and the parameter source. It could be slightly richer in explaining when to prefer this over related tools like get_accounts or get_buying_power, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining that account_seq is 'the numeric accountSeq returned by get_accounts().' This adds meaning beyond the bare schema property and tells the agent where to obtain the value and what type to expect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get portfolio summary and per-symbol positions for one account.' This clearly identifies what the tool does and distinguishes it from sibling tools like get_accounts, which lists accounts, and get_buying_power, which focuses on available funds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is used for a single account's holdings and tells the agent that account_seq comes from get_accounts(). It does not explicitly name alternatives or exclusion criteria, but the one-account scope and read-only labeling provide enough context for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral disclosure burden. It usefully explains that the underlying endpoint returns full filing history in one call without a date parameter, and that date filtering and result limiting are applied after fetching. It also documents the 365-day default behavior. Full pagination, rate-limit, or failure behavior are not covered, but the key post-fetch processing trait is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then organized into a clear Args section. Every sentence adds value: the endpoint behavior, the default date range, the rationale for that default, and the parameter formats. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values do not need to be described. The description covers purpose, endpoint behavior, defaults, and most parameter semantics. It is slightly incomplete because the 'limit' parameter is not documented and no explicit alternation guidance is provided against sibling shareholder reporting tools, but it is otherwise sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains corp_code with an example, and start_date/end_date with format and default semantics. However, the 'limit' parameter, which appears in the schema, is never described even though the prose mentions 'result limit'. This omission leaves one of four parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get 5%-rule major shareholding disclosure reports', further clarified by the Korean term and the reference to the Open DART endpoint. This clearly distinguishes it from sibling tools like get_major_shareholder_status by focusing on the 5%-rule disclosure reporting concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it applies when an investor's holding crosses a disclosure threshold under the 5% rule, and notes that filings are relatively infrequent. It does not explicitly name alternatives or give when-not-to-use guidance, but the intended use case is strongly implied by the threshold-crossing explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses pagination semantics via the 'before' cursor and 'nextBefore' from a prior response, explains the adjusted-price flag, and notes the single-symbol limitation. It does not mention auth, rate limits, or invalid-symbol behavior, but these are minor for a read-only data fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence summary is front-loaded and precise. The Args list is organized and non-redundant, with each parameter explanation adding necessary detail. The Korean translation is a minor redundancy but does not detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no description. The definition covers every parameter's constraints and defaults, provides examples, and explains the pagination flow, making the tool callable without external docs. It omits explicit auth or rate-limit context, but for a data-retrieval tool this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section thoroughly documents all five parameters: accepted interval values ('1m', '1d'), count range (1-200), cursor semantics, symbol format examples, and the adjusted flag. This fully compensates for the uninformative schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb and resource: 'Get OHLCV candle-chart data for a single symbol.' This clearly distinguishes it from sibling tools like get_current_price or get_recent_trades, and the single-symbol constraint is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for the tool's purpose and includes constraints like only one symbol per call and cursor-based pagination, but it does not explicitly name alternatives or state when not to use this tool. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It states the resource and the optional date, but it does not clarify the meaning of 'around' (exact date vs range), timezone handling, or behavior on holidays/non-trading days. This is adequate for a simple read-only lookup but leaves ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is stated in the first sentence, and parameter guidance is formatted as a compact labeled list. The Korean translation is the only redundancy but is brief and does not distract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with an output schema, the description covers both parameters and the market choices. The main remaining gaps are the exact date-range semantics and timezone, but these are unlikely to prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates: market is constrained to 'KR' or 'US', and date is documented as optional YYYY-MM-DD with clear omission behavior. This adds meaning beyond the bare schema and removes ambiguity about accepted values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Get market session times (pre/regular/after-market)'. It also narrows scope by market ('KR' or 'US') and date, making it clearly distinct from sibling price/candle/orderbook tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear invocation context: pass a market and optionally a date, omit the date for today. It does not name alternatives or explicit when-not-to-use, but no sibling tool overlaps with market session times, so this is not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the prose carries the full burden of behavioral disclosure. The description usefully clarifies that the date range applies to filing dates and that this is a fetch from external DART endpoints, but it does not mention API-key requirements, rate limits, pagination, or empty-result behavior. These are meaningful gaps for an external data-retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, endpoint context second, then a clean Args block. The disclosure-type list is long but necessary because the schema provides no enum values, and every line carries useful information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return-value documentation is handled separately. The description fully documents all four inputs, the date semantics, and the available disclosure types. It is only missing operational details such as DART API-key prerequisites and behavior when no disclosures are found, so a perfect completeness score is not warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the parameter documentation in the description is essential and fully compensates. It defines corp_code with format and a concrete example, start_date and end_date with accepted formats and examples, and disclosure_type with all valid values, Korean labels, and the default. An agent can construct a correct call from this text alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get shareholder-return-related disclosure decisions over a date range.' It then enumerates exactly what it fetches (capital increases, capital reductions, treasury stock activity), which makes the tool readily distinguishable from siblings like get_dividend_info or get_financial_statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear usage context: fetching board disclosure decisions from Open DART major-matters reports within a filing-date range, with a defined set of disclosure types. It does not explicitly name sibling alternatives or state when not to use this tool, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does add useful context about the kind of flags returned and symbol formatting, but it does not explicitly state whether the operation is read-only, whether any permission is needed, or how errors or empty results are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence conveys the tool's purpose, and the Args section adds only necessary parameter details. There is no redundant filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers the essential context: what kind of data is returned and how the input must be structured. It is slightly incomplete only in not offering any guidance about choosing between this and related warning/stock-information tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the 'symbol' parameter, so the description fully compensates. It specifies that the symbol must be a single ticker, must not include a market prefix, and gives a concrete example ('005930'), which is exactly what an agent needs to format the argument correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: getting investment-caution flags for a single KRX symbol. It further clarifies the domain with concrete examples like 관리종목/VI, making it easily distinguishable from sibling tools that focus on prices, orders, or company profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool: when you need caution flags for one KRX symbol. It also provides an important usage constraint by requiring a single ticker without a market prefix. However, it does not explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the dialog-by-dialog scanning limitation, the 7-day default window, UTC timezone handling, and file_type exclusions such as voice/video notes. It does not mention limit/pagination behavior, but the core behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then organized into useful parameter details. It is somewhat long and the return-fields list is redundant with the output schema, but every paragraph earns its place and the caveats are meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main invocation concerns: scope, file types, date semantics, and the global-search limitation. The query parameter meaning is not fully specified, which is the main gap; the output schema helps compensate for return-value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so for file_type and since_date in detail, and for chat via the 'globally or in one chat' phrasing. Query and limit are left undocumented, but their names and defaults make them reasonably inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Find messages carrying files, globally or in one chat.' This clearly differentiates from siblings like search_messages and download_file while matching the tool's name. The scope distinction is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool ('globally or in one chat') and references the shared global-search caveat with search_messages. It does not explicitly tell the agent to use search_messages for text-only searches, but the context strongly implies the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses that the tool verifies credentials, session connectivity, and authorization, implying a diagnostic/read-only check. However, it does not state side effects, network behavior, or how failures are returned, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every phrase adds meaningful scope: credentials, StringSession, and authorization all specify what the connection check covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter connectivity test with an output schema present, the description is complete. It names all key preconditions (credentials, session, authorization) and the tool's simple purpose requires no further explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly omits parameter details because there are none to document, and the empty input schema leaves no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('check') and the exact resources checked: Telegram credentials, StringSession connectivity, and account authorization. This clearly distinguishes it from sibling test_connection tools such as dart_test_connection and toss_test_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's scope self-evident by naming Telegram and the specific things it validates, providing clear context for when it applies. It does not explicitly mention alternatives or state when not to use it, but the sibling tools are naturally distinguishable by service name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the key safety behavior: credentials are checked but not exposed. It also implies a local, non-mutating check rather than an API call. It does not specify success/failure return details, but the presence of an output schema reduces that need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly written sentence that names the action, the subject, and a critical non-exposure guarantee. Every word earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter credential-presence checker, the description is highly complete: it states what is checked and the safety constraint. The output schema presumably covers return values. It could further clarify how this differs from toss_test_connection, but that is a minor omission given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there is no parameter documentation burden. The description appropriately focuses entirely on the tool's action rather than arguments. Baseline 4 for a zero-parameter tool is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check'), a specific resource ('TOSS_CLIENT_ID / TOSS_CLIENT_SECRET'), and the precise condition being tested ('were loaded'). It also adds a distinct safety qualifier ('without exposing them'), which separates it from sibling tools like toss_test_connection that actually test connectivity rather than checking local credential presence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for verifying that TOSS credentials are present before use, rather than for testing a live connection or performing any operation. It does not explicitly name when-not-to-use or alternatives, but the context is clear enough that an agent would know this is a preflight environment check, especially alongside toss_test_connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It signals a non-mutating connectivity and credential verification across three named integrations, which is sufficient for a zero-parameter check tool. It does not discuss partial-failure behavior, but an output schema exists to cover result details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the action and names all three target systems with no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter aggregate connectivity check with an output schema, the description covers the needed scope and intent. The only minor gap is that it does not explicitly compare itself to the individual test_connection siblings, though that is easily inferable from the tool names and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully covers parameter semantics. The baseline of 4 applies because there is no parameter information the description would need to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Check'), the exact resources (DART, Toss, Telegram credentials/connectivity), and the combined nature ('in one call'), which clearly distinguishes it from the per-service sibling tools like dart_test_connection and toss_test_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in one call' clearly communicates that this is the aggregate connectivity test, so an agent can infer when to choose it over the individual test_connection tools. It does not explicitly name alternatives or state exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses ordering, default date window, timezone handling, offset semantics, and return fields. However, it omits the `limit` parameter entirely, and the opening 'up to 200' may mislead given the schema default of 50.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a clear summary, followed by compact parameter explanations and a return-field list. Every sentence adds relevant information; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Rich enough for a read-only messaging tool, especially with output schema present. The main gap is the undocumented `limit` parameter and its relationship to the 'up to 200' claim, which an agent needs to select the right invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 0% schema description coverage, the description must compensate. It clearly explains chat, since_date, and offet_id, including formats and defaults. The `limit` parameter is missing, so one of four parameters remains semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific operation (get messages), the resource (one chat), the quantity/ordering (up to 200, newest first), and implicitly distinguishes from siblings like search_messages and list_dialogs. The scope 'from one chat' makes its role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: retrieve recent messages from a single chat, with a default 7-day window and offset-based pagination. It does not explicitly mention alternatives such as search_messages, but the 'one chat' scope and cross-reference to get_channel_info give sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains that the tool downloads the original filing and removes HTML markup to produce plain text, making the read-only, transformative nature of the operation clear. It omits topics such as authentication and error cases, but these are secondary for this simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a clear summary sentence followed by supporting behavior and one parameter explanation. There is no filler, and each sentence adds relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers purpose, behavior, parameter format, and typical usage context. It does not mention authentication or failure behavior, but those are not essential to invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema provides no description coverage, the description's Args section fully documents rcept_no: it is a 14-digit receipt number (접수번호) obtained from search_disclosures or other DART tools. This adds format, source, and context beyond the bare schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Get the plain-text content of one DART disclosure document.' It further clarifies the mechanism (downloads original filing, strips HTML) and ties itself to search_disclosures, distinguishing it from the search-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a clear usage context: 'Useful for reading the details of any filing found via search_disclosures.' This tells an agent when to invoke it, though it does not explicitly enumerate when-not-to-use or compare against other sibling tools in detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses the underlying endpoint, the specific dividend-related fields returned, and the fact that data covers the current and two prior periods. It does not discuss authentication, rate limits, or errors, but for a read-only data retrieval tool the disclosure is substantive and non-misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: a one-line purpose summary, a brief endpoint/data explanation, and a clean Args list. Every sentence adds information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no annotations and no schema-level descriptions, the description covers purpose, all parameters, endpoint details, and returned dividend metrics. An output schema exists, so describing return values in detail is unnecessary. Minor gaps remain around range constraints and error/edge-case behavior, but none are critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only type/title/default with 0% description coverage, so the description fully compensates. It explains corp_code format with a concrete Samsung example, specifies year digit counts with examples, and enumerates every report_type value with Korean report names. This gives the agent everything needed to construct correct arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get dividend-related figures across a range of years,' and further names the exact Open DART endpoint. It clearly distinguishes this tool from sibling financial tools by focusing exclusively on dividend metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: whenever dividend-related figures are needed over a range of business years. It also enumerates report_type options for annual, half-year, and quarterly reports. However, it does not explicitly mention alternative tools or conditions when this tool should not be used, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral disclosure burden. It does so well by stating that it queries the Open DART 최대주주 변동현황 endpoint and returns each change date, the new largest shareholder, and the reason. It does not mention API key requirements or rate limits, but the output schema covers return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, followed by a brief endpoint context and a well-organized Args breakdown. Every sentence earns its place; the length is justified by the need to document parameters without schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only historical query tool, the description is nearly complete: it covers purpose, endpoint, all parameters, examples, and report types. The output schema handles return values. A minor gap is the absence of explicit preconditions such as API key requirements or year-range constraints, though sibling tools hint at the auth context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section fully compensates. It documents corp_code format with a concrete example (Samsung Electronics 00126380), four-digit year expectations, and all report_type values including the default. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names the exact resource: changes in the largest shareholder (최대주주 변동현황) across years. It also explains what the endpoint lists, which clearly differentiates it from sibling status-reporting tools like get_major_shareholder_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear: fetch historical largest-holder change events by date, new shareholder, and reason. It does not explicitly name alternatives or exclusions, but the 'across years' and 'lists each date the largest shareholder changed' phrasing makes the appropriate context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states that each filing's original document is downloaded and parsed because there is no structured JSON API, and it lists the extracted fields (contract amount, period, counterparty). This gives material behavioral insight beyond the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a one-line summary, a purpose/behavior paragraph, and a clean Args block. Every sentence adds information—the Korean disclosure type, the extracted data, the lack of structured API, and clear parameter semantics—without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, input semantics, behavior, and why downloading/parsing is necessary. Since an output schema exists, the description does not need to explain return values. Minor gaps such as pagination, rate limits, or potential cost of reading many filings are not mentioned, but the available context is strong enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only type and title for each parameter, with 0% description coverage. The description compensates fully by explaining each parameter: corp_code is the eight-digit Open DART code with a concrete example, and start_date/end_date are defined as filing-date range boundaries with accepted formats YYYYMMDD or YYYY-MM-DD.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get single sale/supply contract disclosures' and then expands with 'Finds every 단일판매ㆍ공급계약체결 filing for a company in a date range.' This clearly distinguishes it from sibling tools like search_disclosures or get_disclosure_document_text by identifying both the exact disclosure type and the extraction behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is used for tracking order backlog from disclosed sales contracts and notes that this disclosure type has no structured JSON API, which explains why document parsing is needed. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough for an agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so exceptionally. It discloses that the order is not edited in place, the original order_id becomes inactive with status REPLACED, the caller must use new_order_id, and reuse of the old ID returns HTTP 409 already-modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: core purpose and confirmation requirement come first, then market rules, then lifecycle semantics. A small amount of repetition about canceling and replacing appears in both market sections, but it is justified by differing constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers operation semantics, market-specific restrictions, required confirmation, and post-modification order lifecycle. With an output schema available, return-value detail is not needed, but some parameter-level documentation for required fields like account_seq and order_type would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully explains symbol, confirm, order_id, price, and quantity behavior. However, required parameters account_seq and order_type are not described, and confirm_high_value_order is also unexplained, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Modify a live pending order'. It clearly distinguishes this from sibling tools like place_order and cancel_order by scoping to existing pending orders and describing replacement behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: modifications only apply to live pending orders, confirm=True is required, and market-specific constraints dictate whether quantity can be changed. It explicitly states when cancellation and re-ordering is needed instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure responsibility and does it thoroughly. It reveals the 7-day default cutoff, UTC timezone handling, and the important quirk that global search is scan-order biased and not relevance-ranked. These are non-obvious behaviors an agent could not infer from the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence front-loads the core purpose and mode selection, and each following sentence adds necessary parameter or behavioral detail. There is no filler, and the length is justified by the complete absence of schema property descriptions and annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers global vs. chat search, date cutoff semantics, default window, timezone handling, and scan-order bias — all critical for correct invocation. The only minor gap is that chat identifiers (what string or integer represents a chat) are not specified, though the schema allows either and an output schema exists to cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates: since_date gets format, default, and timezone semantics; chat gets 'omit for global search'; limit gets its role in collection cutoff; and query is implied by 'Search message text.' All four parameters receive meaningful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb and resource — searching message text — and immediately distinguishes the two modes: global search or search within one chat. It does not explicitly name sibling tools like get_messages or search_files, but the tool name combined with 'Search message text' makes 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance: omit chat for global search, use since_date to reach older history, and expect a 7-day default window. It does not explicitly discuss when to choose this tool over siblings such as get_messages or search_files, but the context is strong enough to infer the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It transparently explains accepted input forms, best-effort title resolution, ID-resolution failure, and the cache-warming dependency on list_dialogs. It could add error or rate-limit details, but the disclosed behavior is substantial for a read-only metadata lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs with no filler: the first states the return fields, the second covers input forms and failure recovery. All sentences add necessary information, and the most important semantics are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers accepted input variants, a recovery path, and the relationship to list_dialogs. Nothing an agent needs to call it correctly is missing, and return values are presumably handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says chat is a string or integer, but the description explains exactly what those values mean: a @username, a numeric/marked chat ID from list_dialogs, or a best-effort chat title. This fully compensates for the 0% schema description coverage and tells the agent how to construct valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get title, description/about, member count, type, and username for a chat.' This clearly identifies what the tool returns and naturally distinguishes it from message-retrieval siblings like get_messages and search_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete guidance on accepted chat identifiers and a specific fallback: 'call list_dialogs first to warm the client's entity cache, then retry' when ID resolution fails. It does not explicitly state when not to use this tool versus other metadata tools, but the context is clear for a one-parameter lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It meaningfully explains that DART returns the full filing history in one call with no native date parameter, so date filtering and result limiting are applied after fetching. It also warns that large-cap companies can have thousands of filings and that the default limit prevents returning all of them at once.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but the length is earned. The purpose is front-loaded, the Args section is consistently structured, and the extra explanation about post-fetch filtering and default limits is essential behavioral context rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides everything needed to invoke the tool correctly: the underlying data source, the behavior around date filtering, all parameter semantics, and the reason for the limit. Since an output schema exists, explaining return values is unnecessary, and no critical invocation detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate entirely. It does so thoroughly: corp_code is explained with a concrete example, start_date and end_date get accepted formats and default behavior, and limit gets a default, a maximum, and ordering information. Every parameter is meaningfully documented beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-object statement: 'Get executive/major-shareholder stock ownership reports' and then defines the specific resource: filings by executives and major (10%+) shareholders whenever holdings change. This is specific enough to distinguish it from the many shareholder-related sibling tools, even without naming each alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear usage context by explaining that this endpoint covers frequent routine insider-ownership filings and therefore defaults to a three-month window. It does not explicitly name sibling alternatives or state when not to use this tool, but the described behavior gives an agent enough context to choose it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly marks the operation as 'read-only' and clarifies it only retrieves currently sellable shares, implying no side effects. It does not cover auth or rate limits, but for a simple read query this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose statement is followed by two concise parameter bullets. There is no filler, and the core behavior is front-loaded before the arguments.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only query with an output schema present, the description provides the essential information: purpose, read-only nature, account_seq source, and symbol format. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate for parameter documentation. It explains account_seq as the numeric accountSeq returned by get_accounts(), and symbol as a single ticker with no market prefix and an example. Both required parameters are meaningfully documented beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get how many shares of a symbol can currently be sold from one account.' It clearly identifies the operation as a read-only quantity query and distinguishes it from sibling tools like get_holdings, get_buying_power, or place_order by focusing on sellable quantity for a single account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: account_seq should be the numeric accountSeq from get_accounts(), and symbol must be a bare ticker without a market prefix. It implies when to use this tool, but it does not explicitly name alternatives or state when not to use it, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds. It discloses the default download location, subdirectory behavior, rejection of unsafe relative/absolute paths, filename sanitization, and de-duplication against existing files. This makes side effects predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with the core purpose front-loaded in the first sentence. The following sentences add only necessary behavioral detail about destination handling and filename behavior. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-download tool with an output schema and no annotations, this description covers all essential operational context: target location, path-safety rules, and collision handling. Nothing critical needed to invoke it successfully is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter descriptions, so the description must compensate. It does so strongly for dest_dir by explaining subdirectory selection and path-validation rules. However, chat and message_id are only implicitly tied to 'one message' and lack explicit formats or examples, leaving a modest gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific operation: 'Download the file attached to one message to local disk and return its path.' It identifies the resource (a file attachment) and the result (a local path), clearly distinguishing it from sibling tools like search_files and get_messages that retrieve metadata rather than save files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use it when you have a specific chat and message_id and want the attached file saved locally. It explains dest_dir semantics and path restrictions, but does not explicitly name alternatives or state when not to use this tool, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. The verb 'List' clearly implies a read-only operation, and the description explains what each account result contains (accountSeq). It does not explicitly state a read-only guarantee or discuss edge cases like an empty account list, but for a zero-parameter list operation this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence states the tool's core purpose, and the second provides the crucial downstream usage context. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool with an output schema available, the description is complete. It names the resource, identifies the key return field (accountSeq), and explains why that field matters to sibling tools, giving the agent everything needed to invoke and chain the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema declares fully that none are required. The description adds no parameter-level detail, which is appropriate and warrants the baseline score for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, unambiguous action: 'List your Toss Securities accounts.' It names the resource (accounts) and immediately clarifies the primary output (accountSeq). Though there is no direct sibling comparison, no other sibling tool lists accounts, so it is clearly distinguished by its specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly ties this tool to downstream usage: accountSeq is required by get_holdings, get_buying_power, get_commissions, and get_sellable_quantity as their account_seq argument. This tells an agent exactly when to call this tool — before those account-specific tools — making invocation ordering obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral transparency. It discloses the endpoint, the limited return payload, and the post-fetch keyword behavior, which is genuinely useful. It does not cover error cases, API key requirements, or rate limits, but for a straightforward search tool the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and the most important limitation (metadata only). The parameter list is structured and every line adds value, with example values and format hints. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, parameters, output scope, and the key alternative tool. An output schema exists, so return-value details need not be repeated. Minor gaps include no mention of authentication prerequisites or error behavior, but these are secondary for correctly selecting and invoking this search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does: it explains corp_code with a concrete example, gives date format variants, documents every pblntf_ty category code, and clarifies that keyword is applied after fetching since the API lacks title search. This is far richer than the bare input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search DART disclosure filings (공시검색) within a date range.' It clearly distinguishes itself from the sibling get_disclosure_document_text by stating that this tool returns metadata only, while that sibling reads filing content. An agent can immediately tell what this tool does and how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes the agent: use get_disclosure_document_text with a receipt_no to read content, since this tool only returns metadata. It also explains that keyword filtering is applied client-side with no API-side title search, which informs usage expectations. This is direct, practical when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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