ibex35-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have clear individual purposes, but there is significant functional overlap that could cause confusion. For example, 'analyze_trends', 'get_sector_correlation_analysis', and 'get_weekly_reports' all involve trend analysis, while 'get_all_companies', 'get_companies_by_sector', and 'get_companies_with_pe_ratio' are variations of company filtering. Descriptions help differentiate, but the boundaries are not always distinct.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., 'get_company_directors', 'analyze_trends'), with clear action-oriented prefixes like 'get_', 'analyze_', or 'assess_'. However, there are minor deviations such as 'execute_custom_query' (which uses 'execute' instead of 'get') and 'screen_opportunities' (which uses 'screen' as a verb), slightly breaking the pattern but remaining readable.
Tool Count2/5
With 27 tools, the set feels overly heavy and potentially redundant for the IBEX 35 financial analysis domain. Many tools could be consolidated (e.g., multiple 'get_' queries for companies), leading to a bloated interface that may overwhelm agents and increase misselection risk, despite the broad scope.
Completeness5/5
The tool surface is highly complete for financial and governance analysis of IBEX 35 companies. It covers data retrieval (e.g., company info, prices, news), analysis (e.g., trends, risk, reports), and screening (e.g., opportunities), with no obvious gaps. Agents can perform comprehensive workflows from basic queries to advanced analytics without dead ends.
Average 3/5 across 27 of 27 tools scored.
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?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a read-only operation, requires authentication, has rate limits, returns paginated results, or what the output format might be, which is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately sized. However, it's not front-loaded with critical details like scope or alternatives, which slightly reduces its effectiveness despite the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of shareholder data, no annotations, no output schema, and 1 parameter, the description is incomplete. It doesn't explain return values, data scope, or behavioral traits, making it insufficient for an agent to use the tool effectively without guesswork.
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 description adds no parameter semantics beyond the input schema, which has 100% coverage and documents the single 'companyId' parameter. Since schema coverage is high, the baseline is 3, and the description doesn't compensate with additional context like ID format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get shareholders for a specific company' clearly states the verb ('Get') and resource ('shareholders'), but it's vague about scope (e.g., all shareholders vs. top ones) and doesn't distinguish from siblings like 'get_top_shareholders_by_sector' or 'get_shareholder_overlap'. It avoids tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare to sibling tools like 'get_top_shareholders_by_sector' for filtered results or 'get_shareholder_overlap' for relational data, leaving usage context implied at best.
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 full burden for behavioral disclosure. It mentions analysis but doesn't specify whether this is a read-only operation, if it requires authentication, rate limits, or what the output entails (e.g., data format, potential side effects). The description is too vague to inform the agent about key behavioral traits beyond the basic action implied by 'analyze'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence 'Analyze sector performance correlations and market trends', which is front-loaded and wastes no words. However, it could be more structured by including key details like output format or usage context, but as-is, it's efficiently phrased without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'analysis' and lack of annotations or output schema, the description is incomplete. It doesn't explain what the analysis returns (e.g., correlation coefficients, trends data), how results are formatted, or any behavioral aspects. For a tool with no structured data to supplement it, the description should provide more context to be fully actionable 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?
The input schema has 100% description coverage for its single parameter 'days', with a clear description and default value. The tool description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'days' affects the analysis or any constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analyze sector performance correlations and market trends' states a general purpose but lacks specificity. It mentions 'sector performance correlations' and 'market trends' but doesn't clarify what analysis is performed (e.g., statistical correlation metrics, visualizations, or summary insights). It doesn't distinguish from siblings like 'analyze_trends' or 'get_network_analysis', which could overlap in analyzing trends or relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings such as 'analyze_trends' and 'get_network_analysis', the description doesn't indicate specific contexts, prerequisites, or exclusions for selecting this tool over others. Usage is implied only by the tool name and vague description, leaving the agent to guess based on incomplete information.
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 'process and execute' but doesn't clarify what execution entails—whether it returns data, generates reports, or performs analyses. There's no information about performance characteristics, error handling, or output format. The description is too vague about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality. It avoids unnecessary words and gets straight to the point. However, it could be slightly more structured by explicitly mentioning the tool's domain scope upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'complex natural language queries' and the lack of annotations and output schema, the description is insufficient. It doesn't explain what kind of results to expect, how queries are processed, or any limitations. For a tool with no structured output documentation, the description should provide more context about the execution outcome.
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 input schema already documents both parameters thoroughly. The description doesn't add any meaningful semantics beyond what's in the schema—it doesn't explain how the 'query' parameter should be structured beyond 'natural language' or how 'context' integrates with processing. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Process and execute complex natural language queries about companies, financials, governance, or markets.' It specifies the verb ('process and execute'), resource ('natural language queries'), and domain scope. However, it doesn't explicitly differentiate from siblings like 'execute_custom_query' or 'analyze_trends' that might overlap in functionality.
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. With many sibling tools available (e.g., 'analyze_trends', 'compare_companies', 'execute_custom_query'), there's no indication of what makes this tool distinct or when it should be preferred over others. Usage is implied by the description but not explicitly stated.
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 analyzing trends 'over time' and hints at forecasting with 'include_forecast,' but doesn't specify computational methods, data sources, rate limits, authentication needs, or output format. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves and what results to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It avoids redundancy and wastes no words, though it could be slightly more structured by explicitly listing key features like parameter-driven analysis. Overall, it's appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects like data processing, error handling, or result interpretation, and doesn't compensate for the missing output schema. For a trend analysis tool with multiple analysis types, more context is needed to guide effective use, especially compared to siblings with overlapping functionalities.
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% description coverage, providing clear details for all parameters, including enums for 'analysis_type' and defaults. The description adds minimal value beyond the schema, as it only implies the scope ('stock prices, market performance, or sector movements') without explaining parameter interactions or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing trends in stock prices, market performance, or sector movements over time. It specifies the verb 'analyze' and resources 'stock prices, market performance, or sector movements,' making it distinct from siblings like 'get_historical_prices' (data retrieval) or 'assess_investment_risk' (risk evaluation). However, it doesn't explicitly differentiate from 'get_sector_correlation_analysis' or 'screen_opportunities,' which might involve similar analytical tasks.
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. It doesn't mention prerequisites, such as needing historical data from 'get_historical_prices,' or compare it to siblings like 'get_sector_correlation_analysis' for correlation-specific tasks or 'generate_analyst_report' for formatted outputs. Usage is implied by the purpose but lacks explicit context 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'comprehensive risk assessment' but doesn't specify what that entails operationally—such as data sources, computation methods, output format, or limitations. For a tool that presumably analyzes complex financial/operational data, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could potentially benefit from slightly more detail given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a risk assessment tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the assessment returns, how results are structured, or any behavioral aspects like data freshness or limitations. Given the complexity implied by analyzing market, governance, and operational risks, more context is needed for effective agent use.
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 both parameters thoroughly. The description adds minimal value beyond the schema—it implies the 'target' parameter can be companies or sectors, and lists some risk types that overlap with the enum in 'risk_types'. However, it doesn't provide additional context like examples or usage scenarios for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Comprehensive risk assessment for companies or sectors including market, governance, and operational risks.' It specifies the verb ('assessment') and resource ('companies or sectors'), and lists key risk types. However, it doesn't explicitly differentiate from sibling tools like 'get_esg_scores' or 'screen_opportunities' which might overlap in risk-related analysis.
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. It doesn't mention prerequisites, context for selection, or exclusions. Given sibling tools like 'analyze_trends' or 'compare_companies', there's no indication of when this risk assessment tool is preferred over other analytical options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool compares companies across metrics but does not specify how the comparison is performed (e.g., side-by-side table, aggregated scores), what the output format is, or any limitations (e.g., number of companies, data freshness). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by separating key points. Overall, it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and involves comparing multiple companies across metrics, the description is incomplete. It does not explain the comparison output format, potential limitations, or how results are presented, which are critical for an agent to use the tool effectively. The high schema coverage helps, but behavioral aspects are under-specified.
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 fully documents the parameters 'companies' and 'metrics' with descriptions and defaults. The description adds minimal value beyond the schema by listing example metric types (financial, governance, market performance), but it does not provide additional context like metric definitions or comparison methodology. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing multiple companies across various metrics. It specifies the verb 'compare' and the resources 'companies' and 'metrics' (financial, governance, market performance). However, it does not explicitly differentiate from sibling tools like 'get_sector_correlation_analysis' or 'screen_opportunities', which might also involve comparisons, so it falls short of a perfect score.
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. It does not mention sibling tools or contexts where this tool is preferred, such as for multi-company analysis versus single-company tools like 'get_company_by_symbol'. Without any usage context or exclusions, the agent must infer when to apply 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 of behavioral disclosure. It mentions generating a 'comprehensive' report but lacks details on execution time, data sources, permissions required, rate limits, or output format (e.g., text, PDF). For a tool that likely involves complex data processing, this is a significant gap, 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?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place, making it easy for an agent to parse quickly. There is no redundancy or wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of generating analyst reports, lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like data sources, processing time, or output format, which are critical for an agent to use the tool effectively. The high schema coverage doesn't compensate for these missing contextual elements.
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 (subject, report_type, include_charts). The description adds no additional meaning beyond implying the scope ('company, sector, or market theme'), which is covered by the schema's subject description. Thus, it meets the baseline for high schema coverage without compensating with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a comprehensive analyst report for a company, sector, or market theme.' It specifies the verb ('generate') and resource ('analyst report'), and distinguishes it from siblings like 'get_weekly_reports' (which likely retrieves existing reports) or 'analyze_trends' (which may not produce formal reports). However, it doesn't explicitly differentiate from all siblings, such as 'assess_investment_risk' (which might produce similar outputs), keeping it from a perfect score.
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. It doesn't mention prerequisites, context for selection among report types, or comparisons to siblings like 'assess_investment_risk' or 'get_sector_correlation_analysis'. The agent must infer usage from the description alone, which is insufficient for optimal tool selection.
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 but only states the basic filtering action. It doesn't mention whether this is a read-only operation, what the return format looks like (e.g., list of companies with basic details), potential rate limits, or any authentication requirements. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a simple filtering tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what information is returned about companies (e.g., names, symbols, financial data) or how results are structured. For a tool that presumably returns multiple company records, more context about the output would be helpful.
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% description coverage, with the 'sector' parameter well-documented in the schema itself (including examples like 'Banking, Technology, Energy'). The description adds no additional parameter semantics beyond what's already in the schema, so it 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('companies') with a specific filter ('by sector'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_all_companies' or 'get_top_shareholders_by_sector' beyond the basic filtering aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'get_all_companies' (for unfiltered lists) or 'compare_companies' (for detailed comparisons). The description implies usage for sector-based filtering but offers no context about prerequisites, limitations, or when other tools might be more appropriate.
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. While 'Get detailed information' implies a read-only operation, it doesn't specify what 'detailed information' includes, whether there are rate limits, authentication requirements, error handling, or response format. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple lookup tool and front-loads the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are structured, or potential limitations. Given the complexity implied by sibling tools and the lack of structured data, more context is needed to guide effective use.
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 description mentions the parameter ('by its stock symbol') but adds minimal semantic value beyond what's in the schema, which has 100% coverage and clearly documents the 'symbol' parameter with examples. The baseline score of 3 is appropriate since the schema does the heavy lifting, though the description doesn't enhance understanding of parameter usage.
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 verb ('Get detailed information') and resource ('for a specific company'), specifying the lookup method ('by its stock symbol'). It distinguishes from siblings like 'get_all_companies' by focusing on a single company, but doesn't explicitly differentiate from other company-specific tools like 'get_company_directors' or 'get_company_shareholders'.
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. With many sibling tools that also retrieve company-related data (e.g., 'get_company_directors', 'get_esg_scores', 'get_historical_prices'), there's no indication of what makes this tool distinct or when it should be preferred over others.
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 states the search function but lacks critical details: whether it's case-sensitive, supports fuzzy matching, returns partial matches as implied by the schema, includes pagination or limits, requires authentication, or has rate limits. For a search tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Search for directors by name') and adds necessary context ('across all companies'). There is zero wasted language, and every word earns its place by clarifying scope and action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a search function with no output schema and no annotations), the description is incomplete. It lacks details on return values (e.g., format, fields like director IDs or company affiliations), behavioral traits (e.g., search precision, result limits), and usage context. For a tool with 1 parameter but no structured output or safety annotations, the description should provide more operational context.
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% description coverage, with the 'name' parameter documented as 'Director name or partial match'. The description adds no additional parameter semantics beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 verb ('search') and resource ('directors by name'), specifying it searches across all companies. It distinguishes from siblings like 'get_company_directors' (which likely returns directors for a specific company) by emphasizing the cross-company scope. However, it doesn't explicitly differentiate from other search tools like 'analyze_natural_query' or 'execute_custom_query' that might also handle director searches.
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. It doesn't mention prerequisites (e.g., needing a name input), exclusions (e.g., not for filtering by other criteria), or comparisons to siblings like 'get_company_directors' (for company-specific searches) or 'get_board_interlocks' (for relationship analysis). Usage is implied by the name but not explicitly stated.
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 full burden. It only states the action 'Get' without disclosing behavioral traits such as whether it's a read-only operation, requires authentication, has rate limits, or what the return format looks like. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loaded with the core action. It's appropriately sized for a simple tool, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a data retrieval tool with no annotations and no output schema), the description is incomplete. It lacks details on return values, error handling, or behavioral context, which are crucial for an AI agent to use it correctly, especially with many sibling tools available.
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 the single parameter 'companyId' as optional. The description adds no additional meaning beyond what the schema provides, such as explaining what ESG scores include or how filtering works, but baseline 3 is appropriate when schema does the heavy lifting.
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 verb 'Get' and the resource 'ESG (Environmental, Social, Governance) scores', making the purpose specific and understandable. However, it doesn't differentiate from siblings like 'get_all_companies' or 'get_company_by_symbol', which might also retrieve company data, so it doesn't reach the highest score.
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. With siblings like 'get_all_companies' or 'compare_companies' that might relate to ESG data, there's no explicit mention of context, exclusions, or prerequisites, leaving usage unclear.
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 full burden. It states what the tool does but lacks behavioral details: it doesn't mention if this is a read-only operation, potential rate limits, authentication needs, pagination (beyond the 'limit' param), or what the return format looks like (e.g., list of meetings with fields). For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get EU lobbying meetings') and adds optional filtering. There's zero waste, and every word 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'EU lobbying meetings' entails (e.g., data fields, source), behavioral aspects like safety or performance, or return values. For a tool in a server with many financial/lobbying siblings, more context is needed to guide effective use.
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 both parameters ('companyId' and 'limit') with descriptions. The description adds minimal value beyond the schema by implying filtering by company but doesn't provide additional context like example IDs or usage scenarios. Baseline 3 is appropriate as the schema does the heavy lifting.
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') and resource ('EU lobbying meetings') with optional filtering by company. It's specific about what it retrieves but doesn't distinguish from potential siblings like 'get_most_active_lobbyists' or 'get_all_companies' that might overlap in domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It mentions optional filtering by company but doesn't specify scenarios (e.g., vs. 'get_all_companies' for broader data or 'get_most_active_lobbyists' for different lobbying insights). The description lacks explicit when/when-not instructions or named alternatives.
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 states the tool retrieves data ('Get'), implying a read-only operation, but does not clarify aspects like whether it requires authentication, has rate limits, returns paginated results, or what the output format entails (e.g., list of organizations with counts). For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get organizations with the most EU lobbying meetings.' It is front-loaded with the core purpose, has no unnecessary words, and efficiently communicates the tool's function without redundancy. This makes it easy for an agent to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a ranking tool (implied by 'most active'), no annotations, and no output schema, the description is incomplete. It does not explain how 'most active' is determined (e.g., based on meeting frequency or other metrics), what data is returned (e.g., organization names and counts), or any behavioral constraints. For a tool that likely involves sorting and limiting results, more context is needed to guide effective use.
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% description coverage, with the 'limit' parameter well-documented as 'Maximum number of results' with a default of 10. The description does not add any semantic details beyond this, such as explaining how 'most active' is calculated (e.g., by meeting count) or if other filters apply. Given the high schema coverage, a baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get organizations with the most EU lobbying meetings.' It specifies the verb ('Get'), resource ('organizations'), and scope ('EU lobbying meetings'), making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_lobbying_meetings' or 'get_all_companies,' which could provide similar or overlapping data, preventing a perfect score.
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. It does not mention when this tool is preferred over siblings like 'get_lobbying_meetings' (which might list meetings directly) or 'get_all_companies' (which could include lobbying data), nor does it specify prerequisites or exclusions. This lack of contextual direction leaves the agent to infer usage based on the name alone.
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 full burden but provides minimal behavioral context. It mentions filtering but doesn't disclose source limitations, rate limits, authentication needs, pagination behavior, or what 'Get' entails (e.g., returns metadata vs. full articles). For a tool with no annotations, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple filtering tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple tool with 2 parameters, the description is incomplete. It lacks behavioral details (e.g., what 'Get' returns, limitations), usage context, and doesn't compensate for the absence of structured fields. It's minimally viable but leaves significant gaps.
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 fully documents both parameters. The description adds no additional meaning beyond implying sentiment filtering, which is already clear from the parameter names and schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('news articles'), plus the filtering criterion ('by sentiment'). It distinguishes from siblings like 'get_recent_news' by specifying sentiment-based filtering. However, it doesn't explicitly differentiate from all potential news-related tools beyond the provided list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While 'get_recent_news' is a sibling, the description doesn't mention it or explain when sentiment filtering is preferable. There's no context about prerequisites, timing, 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. It states the tool retrieves data but does not disclose behavioral traits such as whether it requires authentication, has rate limits, returns real-time or historical data, or how 'top performing' is defined (e.g., by return percentage, volume). This leaves significant gaps for an agent to understand operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, resource, and key constraint, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It does not explain what 'top performing' entails, the return format, or any behavioral aspects like data freshness or error handling. For a tool with two parameters and no structured safety hints, more context is needed to guide effective use.
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%, with clear parameter descriptions for 'days' and 'limit'. The description adds minimal value beyond the schema by implying a 'specified period' but does not elaborate on parameter interactions or semantics like what 'top performing' means in relation to these inputs. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb 'Get' and the resource 'top performing stocks', specifying the action and target. It distinguishes itself from siblings like 'get_historical_prices' or 'get_all_companies' by focusing on performance ranking. However, it lacks explicit differentiation from tools like 'screen_opportunities' which might also identify high-performing assets, making it a 4 rather than a 5.
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. It does not mention when-not scenarios or compare to siblings like 'analyze_trends' or 'screen_opportunities' that might serve similar purposes. Without any usage context, the agent must infer based on tool names alone.
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 states a read operation ('Get'), but doesn't mention any behavioral traits such as data freshness, rate limits, authentication needs, or what 'top' means (e.g., by market cap, ownership percentage). This leaves significant gaps for a tool that likely queries financial data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data queries, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'top' entails, the data source, return format, or error handling. For a tool with two parameters and likely nuanced output, more context is needed to ensure reliable agent 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?
The input schema has 100% description coverage, with clear documentation for 'sector' and 'limit' parameters. The description doesn't add any semantic details beyond the schema, such as examples of sector names or context for the limit. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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') and target resource ('top shareholders in a specific sector'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_company_shareholders' or 'get_shareholder_overlap', which might have overlapping functionality, so it doesn't reach the highest score.
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. With siblings like 'get_company_shareholders' and 'get_shareholder_overlap' that might retrieve similar data, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
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 full burden for behavioral disclosure. It states the tool 'screens' but doesn't clarify if this is a read-only operation, whether it requires authentication, rate limits, or what the output format looks like (e.g., list of opportunities with details). For a screening tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It includes examples (value, growth, etc.) that add context without unnecessary elaboration. However, it could be slightly more structured by explicitly mentioning the input criteria object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters with nested objects), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what constitutes an 'investment opportunity' in the output, how results are ordered, or behavioral aspects like performance implications. This leaves significant gaps for an agent to use the tool effectively.
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 50%, with detailed descriptions for some parameters (e.g., 'pe_ratio_max', 'governance_quality') but others like 'sectors' and 'exclude_sectors' lack item-level descriptions. The description adds minimal value beyond the schema by listing criteria types (value, growth, etc.), which loosely maps to parameters but doesn't provide syntax or format details. Baseline 3 is appropriate given partial schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Screen for investment opportunities based on specific criteria' with examples like value, growth, dividend, ESG. It specifies the verb ('screen') and resource ('investment opportunities'), but doesn't explicitly differentiate from sibling tools like 'get_companies_by_sector' or 'get_companies_with_pe_ratio' that might overlap in functionality.
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. It mentions criteria types (value, growth, etc.) but doesn't specify contexts, prerequisites, or exclusions compared to sibling tools like 'get_all_companies' or 'execute_custom_query'. This leaves the agent without clear direction for tool selection.
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 states the tool 'gets' companies, implying a read operation, but lacks details on permissions, rate limits, pagination, or output format. The description does not contradict annotations, but it fails to provide essential behavioral context for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with no redundant or verbose elements, making it easy for an agent to parse quickly.
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 (filtering by numeric range), no annotations, and no output schema, the description is minimally adequate. It specifies the filtering criterion but lacks details on output format, error handling, or integration with other tools. The description is complete enough for basic use but leaves gaps in behavioral and contextual information.
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%, with both parameters ('minPE' and 'maxPE') clearly documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the P/E ratio concept, default values, or handling of edge cases. Baseline 3 is appropriate when the schema fully covers parameters.
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 companies filtered by') and the resource ('companies'), specifying the filtering criterion ('P/E ratio range'). It distinguishes from generic sibling tools like 'get_all_companies' by focusing on P/E ratio filtering, but does not explicitly differentiate from other filtering tools like 'get_companies_by_sector' beyond the criterion.
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. It does not mention prerequisites, context for P/E ratio analysis, or comparisons to other filtering tools (e.g., 'get_companies_by_sector' or 'screen_opportunities'), leaving the agent to infer usage based solely on the tool name and description.
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 states the tool 'Get[s] historical price data', implying a read-only operation, but doesn't specify data format (e.g., time series), access permissions, rate limits, or error conditions. For a tool with no annotation coverage, this leaves significant behavioral 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 a single, efficient sentence with zero waste: 'Get historical price data for a company'. It is appropriately sized and front-loaded, directly stating the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters with full schema coverage, the description is minimally adequate. It covers the basic purpose but lacks behavioral details (e.g., data format, errors) and usage context. For a simple read tool, it meets the minimum viable threshold but has clear gaps in 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?
Schema description coverage is 100%, with clear parameter descriptions in the schema (e.g., 'Company ID', 'Number of days of historical data'). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get historical price data for a company', specifying the verb 'Get' and resource 'historical price data' with the target 'company'. It distinguishes from siblings like 'get_company_by_symbol' or 'get_all_companies' by focusing on price data, but doesn't explicitly differentiate from tools like 'analyze_trends' or 'compare_companies' that might involve price data indirectly.
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. It doesn't mention prerequisites (e.g., needing a company ID), exclusions (e.g., not for real-time data), or comparisons to siblings like 'get_company_by_symbol' for company details or 'analyze_trends' for analysis. Usage is implied only by the purpose statement.
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 states the tool retrieves analysis but doesn't specify if it's read-only, requires authentication, has rate limits, or describes the return format. This leaves significant gaps for a tool that likely involves complex data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'comprehensive network analysis' and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'comprehensive' entails, the scope of analysis, or the expected output format, making it incomplete for effective agent use.
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 0 parameters with 100% coverage, so no parameter information is needed. The description doesn't mention parameters, which is appropriate, earning a baseline score of 4 for not adding unnecessary details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('comprehensive network analysis of board interlocks and shareholder relationships'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_board_interlocks' or 'get_shareholder_overlap', which appear related, so it doesn't reach the highest score.
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, such as the sibling tools 'get_board_interlocks' or 'get_shareholder_overlap'. It lacks any context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
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 states the tool retrieves news articles but lacks details on permissions, rate limits, data freshness, or response format. For a read operation with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get recent news articles') and adds a clarifying detail ('optionally filtered by company'). There is no wasted verbiage, 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.
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 (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks guidance on usage, behavioral traits, and output details. With no output schema, it should ideally hint at return values, but the simplicity of the tool keeps it at a baseline 3.
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 fully documents both parameters. The description adds marginal value by mentioning optional filtering by company, which aligns with the 'companyId' parameter, but doesn't provide additional syntax or format details beyond what the schema already specifies.
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 verb ('Get') and resource ('recent news articles'), and specifies optional filtering by company. It distinguishes from siblings like 'get_news_by_sentiment' by focusing on recency rather than sentiment analysis. However, it doesn't explicitly contrast with all news-related siblings, keeping it at a 4.
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 'get_news_by_sentiment' or other news-related tools. It mentions optional filtering but doesn't explain scenarios where filtering is beneficial or when other tools might be more appropriate, leaving the agent with minimal usage context.
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 'generated weekly reports and analysis' but doesn't specify whether this is a read-only operation, what permissions are needed, how data is returned (e.g., format, pagination), or any rate limits. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes directly to the purpose without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, or output format. Without annotations or an output schema, more completeness would be beneficial, but it meets a basic threshold for a simple 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?
The input schema has 100% description coverage, clearly documenting both parameters with enums and defaults. The description adds no additional meaning beyond the schema, such as explaining what 'weekly' entails or how 'analysis' is structured. With high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
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 verb ('Get') and resource ('weekly reports and analysis'), making the purpose understandable. However, it doesn't differentiate this tool from similar siblings like 'generate_analyst_report' or 'get_historical_prices' that might also provide reports or data, leaving some ambiguity about its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like 'generate_analyst_report' and 'get_historical_prices' that could overlap in providing reports or analyses, the description offers no context on prerequisites, typical use cases, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states what data is retrieved but doesn't cover aspects like rate limits, data freshness, authentication needs, or potential errors. This is a significant gap for a data-fetching 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 a single, efficient sentence that front-loads the key information (verb, resource, scope, data) with zero waste. Every word 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It covers the purpose and data scope but lacks behavioral details like data format or limitations, making it minimally viable for a read-only 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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds value by specifying the scope (IBEX 35 companies) and data returned (current prices and key metrics), which compensates appropriately.
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 verb 'Get' and the resource 'IBEX 35 companies', specifying the scope and data returned (current prices and key metrics). It distinguishes from siblings like get_companies_by_sector or get_company_by_symbol by focusing on all companies in the index, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_companies_by_sector or get_top_performers. The description implies usage for retrieving all companies in the IBEX 35, but lacks explicit context 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about return format (e.g., list of directors with details), pagination, rate limits, authentication needs, or error handling. For a read operation with no annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple lookup tool and front-loaded with the essential information. Every word earns its place in this concise formulation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple but undocumented return type, the description is incomplete. It doesn't explain what the tool returns (e.g., list of director objects with fields like name, title, tenure) or any behavioral aspects. For a tool that presumably returns structured data about directors, more context about the response format would be helpful.
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% with one parameter clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 verb 'Get' and resource 'board directors for a specific company', making the purpose immediately understandable. It distinguishes from siblings like get_company_shareholders or get_directors_by_name by specifying it's about board directors for a company. However, it doesn't explicitly differentiate from get_all_companies or get_company_by_symbol beyond the resource focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need board directors for a company, but provides no explicit guidance on when to use this versus alternatives like get_directors_by_name or get_company_shareholders. The input schema suggests using get_company_by_symbol first to get the ID, which offers some implied context, but the description itself lacks clear when/when-not 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 states the tool 'finds' shareholders, implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this is a significant gap in 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, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a tool with no parameters, making it easy for an agent to parse quickly.
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 no parameters, no output schema, and no annotations, the description is minimally adequate. It explains what the tool does but lacks details on behavioral traits, return values, or usage context. This leaves gaps in completeness, especially since it's a read operation that might benefit from output format clarification.
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 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description doesn't need to add parameter details, and it appropriately avoids redundancy. A baseline of 4 is applied since no parameters are present, and the description doesn't introduce confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find shareholders who own stakes in multiple IBEX 35 companies.' It specifies the verb ('find'), resource ('shareholders'), and scope ('multiple IBEX 35 companies'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_company_shareholders' or 'get_top_shareholders_by_sector,' which prevents a perfect score.
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. It doesn't mention prerequisites, context, or exclusions, nor does it compare with similar tools like 'get_company_shareholders' or 'get_top_shareholders_by_sector.' This lack of usage instructions leaves the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions 'SELECT only' which implies read-only behavior, but doesn't address permissions needed, rate limits, result format, pagination, error handling, or query execution constraints. The description doesn't contradict annotations (none exist), but provides inadequate transparency for a database 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?
Extremely concise single sentence with zero wasted words. Front-loaded with the core purpose, and the parenthetical '(SELECT only)' efficiently conveys a critical constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a database query tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (result format, structure, or limitations), nor does it address safety considerations despite the 'SELECT only' hint. Given the complexity of SQL execution and lack of structured metadata, more context is needed.
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 fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute a custom SQL query') and resource ('on the database'), with explicit scope limitation ('SELECT only'). It distinguishes this tool from siblings by focusing on raw SQL execution rather than predefined analytical functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'SELECT only' restriction, suggesting this is for read-only data retrieval. However, it provides no explicit guidance on when to use this vs. the many specialized sibling tools (e.g., get_historical_prices, get_esg_scores), 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't specify whether this is a read-only operation (implied by 'Find'), what data sources or timeframes are used, how results are structured, or any limitations (e.g., rate limits, authentication needs). For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It directly answers 'what does this tool do?' in a compact form, making it easy for an AI agent to parse and understand quickly.
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 complexity (identifying interlocks across multiple companies) and the lack of both annotations and an output schema, the description is minimally adequate. It specifies the resource scope but doesn't address behavioral aspects like data freshness, result format, or error conditions. For a tool with no structured metadata, more context would be helpful to ensure reliable agent usage.
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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds value by clarifying the semantic scope ('IBEX 35 company boards'), which isn't captured in the empty schema. This compensates adequately, though a perfect score is reserved for cases where parameter semantics are more complex.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find directors') and the precise resource scope ('who serve on multiple IBEX 35 company boards'). It effectively distinguishes this tool from siblings like 'get_company_directors' (which gets directors for a single company) and 'get_directors_by_name' (which finds directors by name), making the purpose unambiguous and well-differentiated.
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 identifying directors with board interlocks within the IBEX 35 index, but provides no explicit guidance on when to use this tool versus alternatives like 'get_network_analysis' (which might include interlock analysis) or 'get_shareholder_overlap'. It also doesn't mention prerequisites or exclusions, leaving usage context somewhat open to interpretation.
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:

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

Score Badge

Copy to your README.md:

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

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