borsdata-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but some overlap exists between similar operations such as get_reports vs get_all_reports, get_latest_prices vs get_prices_by_date, and the various KPI tools. Descriptions clarify these boundaries, preventing serious confusion.
Naming Consistency4/5
The naming pattern is predominantly verb_noun with get_, search_, and list_ prefixes, which is consistent. Minor inconsistencies exist, such as 'all' meaning different things in get_all_reports vs get_kpi_all, and the mix of get_prices_by_date vs get_stock_prices.
Tool Count3/5
With 30 tools, the server is on the heavier side, but the broad scope of a financial data API covering instruments, prices, reports, KPIs, corporate actions, and reference data justifies the count. It's borderline between 'slightly over' and 'too many' for the domain.
Completeness4/5
The tool surface covers the core functionality of the Borsdata API well: instrument discovery, price history, reports, KPIs, corporate actions, and calendars. Minor gaps exist, such as lack of global stock splits or more granular corporate action tools, but agents can work around these.
Average 3.9/5 across 30 of 30 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It only restates the 'upcoming' timeframe and the 50-instrument limit already present in the schema. It does not explain return format, error behavior, or other runtime characteristics.
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 concise sentence, front-loaded with the main verb and object, containing no filler or redundancy.
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 no output schema and no annotations, the description covers the core purpose and parameter constraint. However, it omits details about what the response looks like and when this tool should be preferred over similar siblings, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (instList described as 'Array of instrument IDs (max 50)'). The description adds no new semantic meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 a specific action ('Get upcoming report release dates') and a resource constraint ('up to 50 instruments'). It distinguishes itself as a calendar/release-date tool, though it doesn't explicitly contrast with sibling tools like get_all_reports or get_reports_batch.
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. Sibling tools have similar names and purposes, but no exclusions or alternative recommendations are given.
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. It discloses the Pro+ subscription requirement, which is an auth need, but does not mention return format, pagination, or data scope beyond the name. This partial disclosure merits a 3.
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 two short sentences with no waste. It front-loads the core function and adds a necessary subscription note.
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?
Without an output schema or annotations, the description needs to clarify what a 'Global instrument' is, what fields are returned, and how it relates to list_instruments. It leaves the agent guessing, especially given the ambiguous sibling tools.
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 the schema coverage is trivially 100%. The description adds no parameter information, but with no parameters the baseline is 4, and there is nothing to compensate for.
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 lists all Global instruments, which is a specific verb+resource+scope. It differentiates from search_global_instruments by using 'all', but does not explicitly name alternatives, so a small deduction.
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 list_instruments or search_global_instruments. It only mentions a subscription requirement, which is a prerequisite rather than usage guidance.
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 a limit ('up to 50 instruments') but does not explain return format, date range, or any side effects. The description adds minimal context beyond the 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 a single, tight sentence with no redundant wording. It conveys the essential purpose and a key limitation in a highly efficient manner, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one fully documented parameter, the description is largely complete. It explicitly states the output nature (dividend dates and amounts) and the input limit, giving the agent enough context to decide when to use it. Minor gaps like date range specifications are absent but not critical for this tool.
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 100%, so the parameter is already fully documented. The description adds no new semantic meaning about the parameter, merely repeating the max 50 constraint. This meets the baseline for high schema coverage but does not enhance it.
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 clearly identifies the resource ('dividend dates and amounts'). It also includes a scope limitation ('up to 50 instruments') which helps distinguish it from sibling tools like get_prices_by_date or get_reports.
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 explicit guidance on when to use this tool versus alternatives. It simply states what it does, leaving the agent to infer usage context from the name and sibling list rather than receiving direct instructions.
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 only restates the tool's basic function without explaining return format, pagination, side effects, or any performance considerations. An agent is left uncertain about what the 'summary' contains or how it behaves.
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 concise sentence that front-loads the verb and resource. There is no wasted wording or redundancy, making it easy to parse.
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 read tool, the description is functional but incomplete. It does not clarify what 'summary' includes, what the return structure looks like (no output schema), or how it differs from the many KPI-related sibling tools. Given the large sibling set, a bit more contextual detail would improve completeness.
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?
The input schema has 100% coverage, so all three parameters are well documented. The description adds no additional meaning beyond the schema; mentioning 'one instrument and report type' simply echoes the insId and reportType fields. Thus, the baseline of 3 is appropriate.
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 action ('Get a summary') and the resource ('all available KPI values') with scope ('one instrument and report type'). It is specific and conveys a distinct purpose, though it does not explicitly differentiate from sibling KPI tools like get_kpi_all or get_kpi_history.
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 by specifying the scope: 'for one instrument and report type.' This implicitly tells when to use it, but it does not mention alternatives or situations where other KPI tools would be more appropriate, so it lacks explicit exclusions.
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. It mentions the max batch size, but that is already in the schema. It does not disclose return format, potential partial failures, rate limits, or any other behavioral traits beyond the 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 a single, front-loaded sentence that directly states the tool's purpose. No unnecessary words or repetition of schema details.
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?
With no output schema, the description should explain the return structure or at least mention that results are grouped per instrument. It does not. The complexity of a batch call with 5 parameters and 2 enums is not fully addressed, leaving potential user uncertainty about response shape and edge cases.
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 100%, so the baseline is 3. The description adds no new parameter information beyond what the schema already documents (e.g., instList, priceType). It only restates the batch aspect, which is already in the schema's maxItems constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (get), the resource (historical KPI values), and the batch scope (multiple instruments, max 50 in one call). This distinguishes it from sibling tools like get_kpi_history for single instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in one call' and 'multiple instruments' gives clear context for when to use this batch tool. However, it does not explicitly mention alternatives or exclusion conditions, such as using get_kpi_history for a single instrument.
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 description carries full burden. It states read-intent via 'get' but does not disclose any side effects, permissions, rate limits, or response behavior. The instruction to read guides is helpful but doesn't describe the tool's own behavior beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with primary purpose, then supplementary reading references. Zero redundant content; every clause earns its place.
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?
With no output schema and no annotations, description covers purpose and parameter discovery but omits expected return value structure, error behavior, and authentication requirements. It is minimally sufficient for a simple get tool but not rich enough to fully prepare the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all 4 parameters with descriptions and enums (100% coverage). Description adds value by directing agent to kpi-metadata resource for kpiId lookup and api-overview for calcGroup/calc explanations, which helps the agent select valid parameter values beyond the schema's enum constraints.
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 specific verb 'get' and identifies resource 'specific KPI value for one instrument', clearly differentiating from siblings like get_kpi_all (which suggests multiple instruments) and get_kpi_history (historical series). No ambiguity.
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?
Implied usage: use for a single KPI of a single instrument. Provides prerequisites (reading metadata/guide resources) but does not explicitly state when to choose this over alternatives like get_kpi_history or get_kpi_all, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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; it only restates purpose and points to an external reference for field names. It discloses no behavior about response shape, limits, default currency behavior, or failure cases, leaving the agent to infer safety and side effects from the name.
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 front-loaded purpose and a useful reference pointer; no filler or repeated schema details.
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 core invocation is understandable and the reference resource helps with field names, but there is no output schema or annotations, and the description doesn't cover return format, default behavior, or alternative selection. For a 4-param tool with close siblings, this is adequate but not rich.
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?
The input schema already describes all four parameters with 100% coverage, so the baseline is 3. The description adds the report content list and single-instrument scope, but does not add semantic detail for maxCount or original beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('financial reports') plus the key scope ('for one instrument by report type'). It also enumerates report contents (income statement, balance sheet, cash flow), clearly distinguishing this single-instrument tool from siblings like get_reports_batch.
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 crisply states the intended context: one instrument and a specific report type, which tells an agent when this tool fits. It does not explicitly name alternatives or exclusions, so it misses the top-tier 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states that it retrieves report types in one call, without mentioning any side effects, error handling, rate limits, or response structure. For a read operation, the absence of side effects is implied, but not explicitly stated, and no additional context is given.
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 concise sentence with no redundant words. It is front-loaded with the action and scope.
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 is adequate for a straightforward batch-retrieval tool, but since there is no output schema and no annotations, it does not fully explain the response format or potential limitations. With all parameters documented in the schema, the main gap is the absence of return structure details.
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 100%, so the schema already documents all parameters. The description adds no parameter-specific information beyond mentioning the max 50 limit, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (all report types), and the scope (multiple instruments with max 50). This distinguishes it from sibling tools like get_reports and get_all_reports, indicating a batch operation.
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 'for multiple instruments (max 50) in one call' implies that this tool should be used when retrieving reports for several instruments at once, as opposed to a single-instrument tool. However, it does not explicitly name alternatives or state when not to use it, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the batch capability and max 50 instruments, but omits any details about output format, error handling on exceeding the max, whether the operation is read-only (though implied by 'Get'), or any rate limits. This is minimal disclosure for a tool with no 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 a single, concise sentence that front-loads the action and scope. There is no unnecessary information or repetition of schema details.
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 tool is simple with well-documented parameters, but there is no output schema. The description does not explain what the returned data looks like (e.g., structure, adjusted prices, date range handling). Given the absence of annotations and output schema, the description provides the minimum viable context but leaves some gaps for a batch retrieval tool.
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 100%, so each parameter already has a clear description in the schema. The tool description adds no extra semantic meaning beyond emphasizing 'multiple instruments (max 50),' which is already captured in the instList parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get historical stock prices for multiple instruments (max 50) in one call.' The verb 'Get' is specific, the resource is 'historical stock prices for multiple instruments', and the scope 'max 50 in one call' distinguishes it from the likely single-instrument sibling 'get_stock_prices'.
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 intended use clear: for multiple instruments in a single batch call. It does not explicitly name alternatives or state when not to use it, but the context of 'multiple instruments' and the 'batch' name effectively signal the primary use case relative to siblings.
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. It adds only the Pro+ subscription requirement and a 50-instrument limit (which duplicates the schema). It does not disclose return format, error behavior, or any other operational quirks, leaving the agent with minimal behavioral context.
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, front-loaded with the primary action. Every word adds value: the action, the data scope, the limit, and the access requirement. 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?
For a simple single-parameter read tool, the description covers the essential selection and invocation criteria: what data, which instruments, and any restrictions. The absence of an output schema is not critical here, though return details would improve completeness. The description is adequate for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers instList with 100% description. The tool description adds the 'Nordic' qualifier, which clarifies the type of instruments expected. This extra context helps the agent understand what identifiers to pass, going slightly beyond the schema's generic 'instrument IDs'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Get share buyback data' specifies the exact action and data type. The description also scopes to 'Nordic instruments' and a limit of 50, distinguishing it from other market-data siblings like get_stock_prices or get_short_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for buyback data but does not explicitly state when to prefer this tool over alternatives or provide exclusions. It mentions the Nordic scope and Pro+ requirement, which are contextual, but no direct comparison with sibling 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, the description carries the full burden of behavioral disclosure. It adds the useful detail that both Swedish and English descriptions are returned and the limit of 50 instruments. However, it does not mention the return format, error behavior, or whether any permissions are required, leaving some opacity.
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. It is concise and every word adds value: action, resource, language variety, and limit. 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 tool is simple with one parameter and no complex behavior. The description, together with the schema, provides enough to understand input and output. It lacks only minor details like response structure or error handling, which are not critical for a straightforward retrieval.
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?
The input schema documents the only parameter well ('Array of instrument IDs (max 50)'), so schema coverage is 100%. The description adds little beyond the schema, merely reflecting the 'up to 50' limit. This meets the baseline for high schema 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 action ('Get'), the resource ('descriptions'), and the scope ('Swedish and English', 'up to 50 instruments'). This uniquely identifies the tool among its siblings, which focus on prices, reports, or listings rather than descriptions.
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 is implied by the tool's purpose: it is used when instrument descriptions are needed. However, the description provides no explicit guidance on when to prefer it over alternatives like list_instruments or search_instruments, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only mentions the Pro+ subscription requirement, but does not describe return format, pagination, or whether the operation is read-only (though 'get' implies it). This is minimal behavioral context.
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 that efficiently conveys both the purpose and the access requirement. 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 simple tool with one optional parameter and no output schema, the description covers the essential purpose and requirement. However, it lacks explicit guidance on when to use this over similar price tools, and could mention return format. Still, it's adequate for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'date' parameter fully described (format and default). The description adds no additional parameter semantics, which is acceptable given that the schema does the heavy lifting. Baseline 3 applies.
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 resource ('stock prices') with a clear scope ('all Global instruments on a specific date'). This clearly distinguishes it from sibling tools like get_prices_by_date (likely non-global) and get_latest_prices_global (latest vs. specific date).
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 states the context for use: global instruments on a specific date. It does not explicitly mention alternatives or exclusions, but the scope is well-defined. The subscription requirement adds a prerequisite, which helps agents decide if they can use it.
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 must carry full disclosure. It only restates the time window that is already documented in the schema default, and does not describe output format, behavior when 'from' is outside the default range, or any other side effects. This leaves the agent with minimal behavioral insight beyond the name.
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 concise sentence that front-loads the core action and scope. There is no extraneous information, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and full schema coverage, the description is adequate. It states the geographic scope and time constraint, which is enough to understand basic usage. The lack of an output schema means return values are not explained, but the nature of 'stock splits' makes the output predictable.
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?
The schema has 100% coverage for the single parameter 'from' with a clear description. The tool description adds no additional parameter semantics beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'stock splits', and scopes it to 'Nordic instruments' and 'within the last year'. This clearly distinguishes it from all sibling tools, none of which mention splits, and leaves no ambiguity about the tool's function.
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 specifying the geographic scope (Nordic) and the time window (last year), which implicitly tells an agent when this tool applies. It does not explicitly mention exclusions or alternatives, but since no other split tool exists, the context is sufficient.
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 the 'single call' behavior, which is useful, but does not state return format, pagination, or explicitly confirm read-only safety. The verb 'get' implies a read operation, but the absence of explicit behavioral detail is a 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?
The description is a single 12-word sentence, front-loaded with the verb and resource. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, 3 report types) and no output schema, the description provides a high-level purpose but lacks details on response structure or behavior around defaults/limits. An agent may not know exactly what each report type returns.
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 100%, so the baseline is 3. The description's mention of report types (year, r12, quarter) provides context for the maxR12QCount and maxYearCount parameters, but it adds no new syntax or details beyond the schema's existing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (all report types), the specific types (year, r12, quarter), and the scope (for one instrument). This distinguishes it from sibling tools like get_reports (which likely fetches a single report type) and get_reports_batch (multiple instruments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a single call' implies an advantage over calling get_reports multiple times, and the scope 'for one instrument' clarifies the intended context. However, it does not explicitly mention alternatives or exclusion scenarios, so it falls 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?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose that the tool returns thousands of instruments and that the scope includes Nordic and Global with Pro+, which is useful. However, it does not mention whether it is read-only, potential performance implications, or error scenarios, leaving some gaps for a tool of this magnitude.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the core purpose and follow with a practical usage caveat. Every sentence contributes meaningful information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description provides important context about result size and scope, but it does not describe the structure of each instrument record or any error handling. This is a notable gap for a tool expected to return thousands of items, so the description is only partially 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?
The input schema covers 100% of parameter descriptions, including enums for calc and calcGroup. The description adds value by clarifying the 'ALL instruments' context but does not go beyond the schema's parameter descriptions. Baseline 3 is appropriate given the high schema 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 tool's function: 'Get a specific KPI value for ALL instruments' with scope defined as 'Nordic + Global with Pro+'. This specific verb+resource+scope makes it easy to distinguish from sibling tools like get_kpi (which likely targets a single instrument).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Useful for screening and comparing across the market.' It also advises caution about the large result set, suggesting client-side filtering. However, it does not explicitly mention alternatives or when not to use this tool, leaving the differentiation to implication.
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 transparency burden. It discloses an important limitation (only a subset of KPIs have history) and directs to a metadata reference. However, it does not describe return format, error behavior, pagination, or other operational details, which leaves gaps for a tool 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 two sentences, immediately states the core purpose, and includes a necessary caveat without unnecessary detail. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description provides a critical usage prerequisite but omits any description of the return structure. It is adequate for a simple read tool, but missing response details reduces completeness.
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?
The input schema provides 100% coverage with clear descriptions and enum definitions, so the description need not re-explain parameters. The description adds a useful hint about consulting KPI metadata, but that is more about data availability than parameter meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get historical KPI values for one instrument.' This specific verb+resource combination distinguishes it from batch/current KPI siblings, such as get_kpi_history_batch or get_kpi.
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 implies usage context by noting 'for one instrument' (contrasting with batch alternatives) and explicitly instructs reading 'borsdata://reference/kpi-metadata' to identify which KPIs have history. However, it does not explicitly name the alternative for multiple instruments, so it falls short of a full when/when-not guide.
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 tool lists all sectors and that the output includes sector IDs, but lacks details on response format, pagination, or authentication. For a simple read-only list, this is minimally adequate but not rich.
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, each providing distinct information: what the tool does and how the output can be used. No redundancy and every sentence earns its place.
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 tool is simple with no parameters or output schema, so the description covers the core functionality. However, it does not explicitly describe the structure of the returned sector list beyond implying sector IDs exist. This is sufficient for a basic list tool but leaves some ambiguity.
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 the schema is empty (100% coverage). The description adds no parameter-specific information, but with no parameters, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List all sectors') with a specific resource ('sectors'), distinguishing it from sibling tools like list_countries and list_markets. The verb 'List' is explicit and 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 a downstream use case ('Use sector IDs to filter instruments') but does not explicitly contrast with alternatives or state when to use this over sibling tools. It offers indirect usage guidance but lacks exclusions or direct comparisons.
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 clearly indicates a read operation ('Get') and defines the scope (Nordic instruments, specific date), but it does not disclose any potential side effects, required permissions, or return format. This is adequate for a simple getter but lacks depth.
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 two concise sentences. It front-loads the core action and scope, then provides a relevant alternative without unnecessary detail. Every word contributes to understanding the tool.
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 tool with one optional parameter and no output schema, the description is largely complete. It states what it does, its scope, and how to handle global instruments. It could arguably mention return behavior or error cases, but these are not critical for selection and 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?
The input schema covers the only parameter (date) with a clear format and default, so schema description coverage is 100%. The description adds little beyond the schema, which is acceptable. Baseline 3 applies because the schema handles the semantic heavy lifting.
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'), names the resource ('stock prices for all Nordic instruments'), and scopes it ('on a specific date'). It also distinguishes from the sibling get_prices_by_date_global, making the tool's unique 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 explicitly directs users to an alternative for global instruments ('For global instruments, use get_prices_by_date_global'), which serves as a when-not-to-use guideline. However, it does not clarify when to prefer this over other price-related tools like get_stock_prices or get_latest_prices, so some context is still 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 mentions that the operation returns 'full instrument details,' which is a read-only listing. However, it lacks additional context such as potential response size, pagination, or any side effects, though as a list operation these are relatively 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 two sentences, front-loaded with the main action, and every clause earns its place. It succinctly states the scope, optional filters, and return type 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?
Given a simple list tool with no output schema, the description covers the essential aspects: scope, optional filters, and return value. It lacks details on pagination or large result handling, but for a basic list endpoint this is not a critical gap. The description is sufficiently complete for an agent to select and invoke 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?
The schema already provides 100% coverage for all parameters, so the baseline is 3. The description adds meaningful context by stating that filtering is optional, which clarifies that none of the parameters are required and they can be combined. This is a valuable semantic addition beyond the schema's individual property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Nordic instruments'), and clearly differentiates from sibling tools like list_global_instruments by specifying the Nordic scope. It also lists the optional filters, making the tool's function 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 context is clear: use this tool to list Nordic instruments with optional filters. However, no explicit guidance is given on when to prefer this over alternatives such as search_instruments or list_global_instruments, nor are any exclusions or prerequisites mentioned.
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?
Discloses the Pro+ subscription requirement and that it returns IDs, which are useful behavioral context. With no annotations, the read-only nature of search is implicit, but the description does not explicitly state side-effect safety or other limitations.
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?
Three concise sentences covering purpose, requirement, usage, and return. No fluff, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient information for a simple 2-parameter tool: what it does, how to use it, its subscription requirement, and its return. Without an output schema, the return detail (IDs) is adequate for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the schema already documents query and maxResults. The description repeats 'name or ticker' without adding new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search for Global instruments by name or ticker' with specific verb, resource, and scope. The distinction from sibling 'search_instruments' is explicit through 'Global', and examples (Apple, Microsoft) reinforce usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is for global companies, with examples. It implies the alternative (search_instruments for local) by the name/description, but does not explicitly name 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions the subscription requirement, which is a key behavioral constraint. However, it does not describe the return format, potential errors, or whether the result is a list or single value. For a simple read tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core function and adds the subscription requirement. Every word earns its place, and there is no redundancy or filler.
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 zero-parameter tool with no output schema, the description covers the essential function and a prerequisite. However, it lacks detail about the difference from the sibling tool get_latest_prices (the global scope is only implied by the name) and does not describe the response structure. It is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so there is no parameter information to add. Per the rubric, 0 params merits a baseline score of 4, and the description does not need to compensate for any missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the latest stock price for all Global instruments.' It uses a specific verb ('Get'), a resource ('stock price'), and a scope ('all Global instruments'), which distinguishes it from sibling tools like get_prices_by_date_global and get_latest_prices. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for global instruments and includes a prerequisite ('Requires Pro+ subscription'). However, it does not explicitly mention alternatives or when not to use this tool, though the global scope is a strong implicit differentiator. This is better than vague but lacks explicit exclusion 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 goes beyond a simple statement by revealing the time window ('past 10 years'), the nature of data ('buyer/seller activity'), and the subscription constraint. While it does not detail output format or error handling, it adequately discloses the tool's read-oriented behavior and key limitations for a simple query 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 three short sentences, each offering distinct information: purpose, requirement, and data scope. There is no redundancy, and key details are front-loaded in the first sentence. Every sentence earns its place, making it highly concise and well-structured.
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 has low complexity (one parameter, no output schema, no annotations). The description covers the core aspects: what it does, the input constraint, the subscription requirement, and the type of data returned. It does not fully specify the return structure, but the description's mention of 'buyer/seller activity' gives a reasonable picture. Given the simplicity, it is sufficiently 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?
The input schema already documents instList as 'Array of instrument IDs (max 50)' with 100% coverage. The description adds minimal extra meaning by specifying 'Nordic instruments', which clarifies the interpretation of IDs. However, this is a marginal addition beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get insider trading holdings for up to 50 Nordic instruments.' It identifies a specific resource (insider trading holdings), a scope (Nordic instruments, max 50), and there are no sibling tools that overlap with this niche. The verb 'Get' and the subject matter clearly distinguish it from related tools like get_short_positions or get_buybacks.
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 clear usage context by specifying the instrument scope ('Nordic instruments'), the maximum batch size (50), and the subscription requirement ('Requires Pro+ subscription'). It implies when to use the tool (for Nordic insider data) and when not to (if no Pro+ subscription), but does not explicitly mention alternative tools. This meets the 'clear context, no exclusions' bar for a 4.
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 full burden. It states that the tool returns a datetime and explains it indicates data refresh time. However, it does not specify the scope (e.g., whether it covers all KPIs or a specific one), nor does it mention any permissions, rate limits, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action, and contains no unnecessary words. Every sentence contributes meaning.
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 tool with no output schema, the description is mostly complete: it states the return type and purpose. The main gap is ambiguity about whether 'last KPI calculation' is global or per something, which could confuse an agent in a sibling-heavy 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 baseline is 4. There is no parameter information needed, and the description adds value by clarifying what the returned value represents.
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 clearly names the resource: 'the datetime of the last KPI calculation.' This distinguishes it from sibling tools like get_kpi or get_kpi_all, which return KPI values rather than a timestamp.
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 'Useful to know when data was last refreshed' provides a clear use case. However, it does not explicitly mention alternatives or when not to use it, though the distinction from KPI value tools is implicitly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the Pro+ subscription requirement, the large response size (~170KB+), and the regulatory reporting source, all of which are useful behavioral traits beyond the tool's name. It does not describe the return structure, but that is partly mitigated by the large-response warning.
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 sentences, each adding critical information: purpose, subscription requirement, and response size/data source. No redundant words and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides sufficient context: it identifies the data type, geographic scope, subscription requirements, and response size. It could be more complete by describing the response format or how to handle the large payload, but it is largely adequate.
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 the schema is trivially 100% covered. With no parameters to explain, the baseline is 4, and the description adds no unnecessary parameter 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 ('Get') and resource ('short selling positions') with a clear scope ('all Nordic instruments'). It is distinct from all sibling tools, none of which mention short selling positions.
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 when to use the tool (when short selling data is needed) but provides no explicit comparison with alternatives or exclusionary guidance. The unique domain of the tool makes its purpose clear, but the absence of when-not-to-use guidance keeps it at a mid score.
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 full responsibility. It discloses the maximum time range (20 years), the response fields, and the potential for very large payloads without filters. This is transparent about a key operational behavior, though it omits details like error handling or rate limits.
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 exceptionally concise: two sentences cover purpose, data fields, time range, and usage warning. Every sentence adds value, with the main action front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple historical data retrieval tool, the description is complete: it specifies the data fields returned and the time horizon, and warns about response size. A minor gap is not explicitly stating whether the return is an array or single object, but the plural 'prices' and historical context imply a list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters (insId, from, to) already described. The description reinforces the 'from' recommendation and explains the consequence of omitting filters, but it does not add substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving historical end-of-day stock prices for a single instrument. It specifies the data fields returned (date, OHLC, volume) and distinguishes itself from sibling tools like 'get_stock_prices_batch' (multi-instrument) and 'get_latest_prices' (non-historical).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using from/to date filters to limit response size, and warns that omitting filters returns a very large full history. It does not explicitly mention when to use alternatives, though the 'one instrument' scope implies batch tools for multiple instruments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. 'List' implies a read-only retrieval, and the sentence 'Each branch belongs to a sector' adds relational context. However, it does not disclose return format, pagination, or any side effects, which is acceptable but not exhaustive.
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 that directly state purpose and a key use case. No redundancy or filler, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool, the description is mostly complete: it names the resource, gives a hierarchical relationship, and mentions an application. It could mention output structure or whether it's paginated, but given the minimal complexity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially covered. The description adds value by explaining the domain context (branches belong to sectors) and how IDs are used, compensating for the lack of parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all industry branches, a specific verb-resource pairing. It distinguishes from sibling tools like list_sectors by noting branches belong to sectors, providing hierarchical context.
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 a key usage: 'Use branch IDs to filter instruments.' This gives context on when the tool is useful, though it does not explicitly compare with alternatives or 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?
With no annotations, the description carries the burden of behavioral disclosure. It accurately describes the action ('List all Nordic countries') but does not mention output format, ordering, pagination, or any potential side effects. For a simple read-only list, this is minimal but lacks depth.
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 two short sentences with no filler. It front-loads the core purpose before adding a usage hint, making it concise and well-structured.
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 low complexity (no params, no output schema), the description provides enough to understand the tool's basic function and its intended role in the workflow (getting country IDs for filtering). It could specify the response structure, but overall it is reasonably complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema shows 100% coverage. The description's mention of 'country IDs' refers to output data, not input parameters, so it doesn't add parameter semantics. The baseline for 0 params is 4, and nothing reduces it.
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 that it lists all Nordic countries, which is a specific action on a specific resource. It distinguishes itself from sibling list_* tools by being focused on countries rather than instruments, markets, sectors, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence 'Use country IDs to filter instruments' provides a clear context for when to use this tool — to obtain IDs for filtering instruments elsewhere. However, it does not explicitly mention alternatives or when not to use it, so it is not a full usage guide.
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 full burden. It states that the tool lists 'all' markets, which is a useful scoping detail. However, it does not mention return format, pagination, authentication, or potential side effects. For a simple read/list tool, this is adequate but not rich.
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 two short sentences, front-loaded with the primary purpose. Every sentence earns its place: the first states what the tool does, the second explains how to use the result. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description is complete enough. It states the endpoint's purpose and provides a usage hint. It does not detail return fields beyond mentioning IDs, but for a list-all tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to elaborate on input semantics. The baseline for 0-param tools is 4, and the description adds helpful context about the output (market IDs) rather than input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all stock markets (exchanges).' This uses a specific verb and resource, and distinguishes it from siblings like list_countries or list_instruments. The additional note about using market IDs for filtering reinforces its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to obtain market IDs for filtering instruments. While it does not explicitly exclude alternatives or name sibling tools, the purpose is clear enough that an agent would know to use this when market IDs are needed.
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 transparency burden. It conveys a read-only operation ('Get the latest stock price') and scope, but lacks details on data freshness (e.g., real-time vs. delayed), return format, or any potential limitations. For a simple getter, this is acceptable but leaves gaps.
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 exactly two sentences, with the core purpose front-loaded in the first sentence and the alternative guidance in the second. Every word earns its place, with no fluff or redundancy.
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 tool is simple (0 params, no output schema), but the description only says it returns 'the latest stock price' without describing the response format (e.g., list, structure). Since there is no output schema, the agent does not know the shape of the returned data. The description does provide scope and alternative guidance, but completeness is limited by missing return-value details.
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 has zero parameters, so there are no parameter semantics to explain. The baseline for 0 params is 4, and the description correctly adds nothing about parameters, as none exist. No extra guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the latest stock price for all Nordic instruments.' It uses a specific verb ('Get') and resource ('latest stock price') with scope ('Nordic instruments'), and distinguishes itself from the sibling tool get_latest_prices_global by noting that global instruments are covered there.
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 provides usage guidance: for Nordic instruments use this tool, and for global instruments use get_latest_prices_global (Pro+). This directly tells the agent when to choose this tool versus the key alternative, which is clear and actionable.
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 transparency burden. It discloses that the tool returns matching instruments with their IDs and is a search operation, implying read-only behavior. It adds workflow context ('first step to get insId') but doesn't mention rate limits, sorting, or result limitations, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by usage and alternative guidance. Every word adds value with no redundancy or fluff.
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 tool is simple (2 params, no output schema), and the description covers the purpose, what it returns (matching instruments with IDs), when to use it (first step to find insId), and when not to use it (global instruments). The schema covers parameter semantics, so this description is fully sufficient for an agent to select and invoke the tool correctly.
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 100% for both parameters (query and maxResults). The description repeats that query is by name or ticker, matching the schema's own description, and adds no new parameter-level details beyond what the schema already provides. Thus baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Nordic instruments by name or ticker and returns matching IDs. It explicitly differentiates from the sibling tool search_global_instruments by naming the alternative, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this first to find the insId needed for other tools.' It also tells the user to use search_global_instruments for global instruments, clearly defining the scope and alternative.
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:

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

Score Badge

Copy to your README.md:

[![borsdata-mcp-server MCP server](https://glama.ai/mcp/servers/carlwestman/borsdata-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/carlwestman/borsdata-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/carlwestman/borsdata-mcp-server'

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