INDUSS Research Intelligence MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct data source or analytical operation; even similar-sounding tools like negative_news vs litigation_history are clearly separated by source type, and red_flag_screen aggregates rather than gathers.
Naming Consistency4/5
Naming is consistently snake_case and descriptive, but mixes verb-first (search_company, generate_report) with noun-first (company_profile, financial_statements) conventions; this is a minor inconsistency.
Tool Count3/5
23 tools is on the heavy side but justified by the breadth of research functions; it's near the upper bound of what's reasonable.
Completeness4/5
Covers the full research workflow from company discovery to valuation and report generation; minor gaps like a dedicated shareholding-pattern tool are covered indirectly via listed_peer_comparison.
Average 3.9/5 across 22 of 23 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about the sources (company site and LinkedIn) and the narrative format, but it does not disclose output shape, potential source bias, or limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight, front-loaded sentence with no filler. Every clause adds meaning: what it produces, what it contains, and where the information comes from.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and sources, and annotations cover read-only/open-world behavior. However, with no output schema and nested optional parameters, an agent is left to infer the return shape and how fields like sector, country, and listed should be used together. It is adequate for a simple read-only overview but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the top-level context parameter, and the description does not explain any of the nested fields such as company, companyDomain, country, listed, sector, or date. The required company field is inferable from the tool name, but the description does not compensate for the low 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 a specific verb ('Produces') and a concrete deliverable ('narrative business overview') with content details (what the company does, products/services, target market) and sources. However, it does not explicitly distinguish itself from the sibling company_profile tool, so it falls short of 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?
No guidance is given about when to use this tool versus alternatives like company_profile, industry_overview, or market_size. The source qualifier is informative, but it does not tell an agent when to choose this tool or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already marks the tool as readOnly. The description adds that the tool searches multiple external sources, which is a behavioral detail beyond the annotation. However, it does not describe the return format, potential errors, or any pagination/limitations, so it provides only partial 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 concise sentence with no redundant words. It efficiently conveys the core function and sources without any fluff, making it easy to parse and remember.
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 (one nested context object with multiple fields) and lack of an output schema, the description is too minimal to be considered complete. It does not explain how to construct the input or what to expect in response, leaving significant gaps for an agent to fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description provides zero explanation of the input parameters (e.g., company, country, listed, sector, companyDomain). The schema itself has some inline descriptions for certain fields, but the description does not compensate for the low schema coverage (0%). An agent would have no guidance on how to map the purpose to the required context parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving registry-grade company profile facts (CIN, incorporation date, registered office) and identifies the specific data sources (MCA/Tofler/Zauba/OpenCorporates and the company's own site). It is specific and unambiguous, distinguishing it from sibling tools that focus on other aspects like financials or news.
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 does not explicitly state when to use this tool versus alternatives such as company_overview or search_company. It implies a use case for registry facts but lacks direct comparison or conditions, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint by disclosing the method (pattern matching) and the sources (IMARC, Statista, etc.), aligning with openWorldHint. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the purpose and mentions sources and method. No wasted words.
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?
The tool is complex due to a nested context object with several properties, but the description does not explain the input structure or any prerequisites. Without an output schema, the description should at least guide on required fields like sector, but it does not. This is a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the top-level 'context' parameter, and the description provides no information about how to populate it. The required 'sector' field is undocumented, and optional fields like company, country, and date are not explained. The description does not compensate for the schema gap.
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: finding market size and CAGR figures for an industry, and lists specific research sources. It distinguishes from broader tools like industry_overview by focusing on quantitative metrics, though it doesn't explicitly compare to that sibling.
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?
No explicit guidance on when to use this tool versus alternatives like industry_overview. The description implies usage for market size queries but does not state exclusions or conditions that would favor a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful behavioral details: the list of sources and the sort order. However, it does not disclose result limits, pagination, or how the 'open world' aspect might affect output. Given the annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the primary action and key attributes efficiently, 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?
The tool has a complex context object with many optional fields and no output schema. The description fails to explain how these parameters affect behavior (e.g., sector vs company, date, daysBack), nor does it mention any return format or limitations. This is incomplete for an agent to use correctly, especially given the existence of the negative_news sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description makes no mention of any parameters. It fails to explain the required 'context' object, the 'daysBack' field, or the various optional fields like 'sector', 'country', and 'companyDomain'. The description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieves') and a clear resource ('recent news coverage of a company') and names five distinct sources, while noting the sorting by publish date. This clearly distinguishes it from siblings like negative_news or search_company, so an agent can tell when to invoke it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for recent news coverage, but it gives no explicit guidance on when to use it versus alternatives such as negative_news or search_company. There is no mention of exclusions or context where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations readOnlyHint=true and openWorldHint=true adequately cover the read-only nature and possibility of incomplete data. The description adds that it 'extracts candidate facts,' which transparently indicates the output may be provisional. No behavior is hidden or contradicted.
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, well-structured sentence that lists the data sources and the type of information retrieved. It is concise, without unnecessary words, and directly conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a good high-level overview but omits details about output format, potential limitations, or how the 'context' parameter should be used. Given the tool's multi-source nature and the absence of an output schema, a bit more context about expected results or edge cases would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The top-level parameter 'context' has no description in the schema, and the tool description does not explain any of its nested properties (company, country, sector, etc.). While the schema provides descriptions for a few nested fields, the overall parameter semantics are poorly communicated, especially for a required object parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it searches multiple named sources for funding rounds, investors, and valuation mentions, and extracts candidate facts. This distinguishes it from other tools that might provide general company profiles or financial statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as search_company or company_profile. There is no mention of prerequisites, scenarios, or comparison to sibling tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description frames this as a rendering operation and aligns with the idempotentHint annotation. However, readOnlyHint is false and the description does not clarify whether the rendered Markdown is returned directly, saved to a file, or if any side effects occur, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words. It efficiently captures the tool's purpose and key output characteristics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context to understand the input source, output format, and distinctive features like TOC and citation consolidation. It could be slightly more explicit about the return type, but overall it positions the tool well among the sibling report-generation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description does not explain the required title and sections parameters or the nested citations structure. It defers to generate_report's schema rather than adding meaning to the many undocumented fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a structured report into a GitHub-flavored Markdown document, with explicit mention of TOC, per-section confidence/sources, and a consolidated citation list. The verb, input, and output format are all concrete and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the input is a structured report following generate_report's schema and that the output is Markdown, which distinguishes it from PDF generation. However, it does not explicitly explain when to choose Markdown over the PDF or institutional report siblings, nor does it provide workflow prerequisites beyond the schema pointer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint and openWorldHint annotations—it searches external sources and returns results without side effects. It additionally explains the internal methodology (text-pattern heuristics, mention frequency, listed-company signal) and the deterministic top-5 selection, going beyond the annotations to provide insight into how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it packs in multiple steps (search, extract, rank, return) and a caveat about deterministic selection. While it is somewhat long, it remains focused and avoids unnecessary fluff, earning a high score for conciseness with minor structural complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description clarifies that the tool returns a top-5 list and explains the ranking logic, covering the output aspect despite no output schema. However, it does not address how to specify the search target (company vs sector) or other contextual fields, leaving some ambiguity in how to pass the 'context' parameter. Overall, it is reasonably complete for the tool's core purpose but misses parameter-level context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not reference any of the parameters in the 'context' nested object, nor does it explain how to populate them (e.g., when to provide 'company' vs 'sector'). The schema itself has descriptions for only two fields (sector, companyDomain), leaving others undefined, and the tool description adds no clarification. This leaves the agent guessing about required inputs for a nested structure.
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 explicitly states the tool's function: searching industry-analyst and news sources for competitors, extracting candidates, ranking them, and returning a top-5. The verb 'searches' and specific details about the process make the purpose unmistakable, and the deterministic selection note distinguishes it from other tools that might involve model choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering competitors but does not explicitly state when to use it over alternatives. It mentions 'instead of leaving selection to the calling model,' which hints at deterministic behavior, but there is no direct guidance on when to invoke this tool versus others like search_company or comparables_valuation. The context is clear enough for an agent to infer, but explicit guidance is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behaviors like sector fallback, server-ranked competitor list, evidence checklist, and that the closing section directs the caller to add analyst-judgment sections. However, it includes extensive style guidance that is more about the calling model than the tool's own behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, extremely long, repetitive sentence. It includes redundant meta-commentary about writing style and reference institutions, making it poorly structured and not concise.
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?
Provides a detailed overview of report contents and which sibling tools it replaces, but includes extraneous writing-style instructions that could confuse an agent. Lacks any mention of error handling or response structure, though no output schema is expected.
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?
Only the sector parameter receives extra context via the fallback note, aligning with the schema description. Other parameters (listed, country, reportType) are not additionally explained, and schema coverage is moderate at 57%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a complete institutional research report in one call, listing the specific components. It also explicitly distinguishes itself from sibling tools by instructing to use this instead of calling them separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this instead of calling ... separately', giving clear when-to-use guidance relative to alternatives. The fallback behavior for sector omission is also described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and scope. The description adds value by specifying the exact sources (Glassdoor, Reddit) and the categories of adverse media (fraud, layoffs, defaults, controversy), which are behavioral traits beyond the annotations. However, it doesn't describe return format or pagination, so it doesn't fully exhaust the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The purpose is front-loaded, and the alternative is given in a single clear clause. No redundancy or filler.
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?
The tool has a nested object parameter with multiple fields and no output schema, so the description must guide input construction. It does not mention required fields (like company), defaults (like date or country), or what the tool returns. The only useful guidance is the purpose and the sibling routing, but not enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the context parameter. It does not mention that context requires a company name or any other field. The description only explains the tool's purpose, not how to fill its input. This is a critical gap for an agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('screens') and resource ('news and public-sentiment sources' - Glassdoor, Reddit) and clearly distinguishes from litigation_history for hard legal records. The purpose is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative tool (litigation_history) and the condition that selects it ('hard regulatory/legal records'). This is direct routing guidance with no inference needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently states that the tool 'invents no assumptions of its own' and 'reports each case's own validity issues,' making its behavior clear. It also repeatedly notes 'Pure calculation — no search,' which aligns perfectly with the readOnlyHint and idempotent annotations, ensuring no hidden side effects are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and repetitive, repeating phrases like 'Like dcf_valuation' and 'Pure calculation — no search' multiple times. This redundancy adds no new information and detracts from clarity, making it less concise than necessary for the tool's relatively simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the high-level behavior (three DCF runs, optional sensitivity grid) and the role of user-supplied scenarios, but it omits crucial details such as the exact structure of sensitivity axes, how companyName is used, or what output is produced. Given the tool's moderate complexity with nested objects and no output schema, the description provides enough to understand the general workflow but is incomplete for full autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only refers to 'deltas' and 'grid values' without mapping them to specific parameter names like baseAssumptions, bullDelta, bearDelta, sensitivity, or companyName. Since schema coverage is only 20% and the tool has nested structures, the description does not sufficiently compensate for the lack of per-parameter explanations, leaving many parameters undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it runs the same DCF three times (base, bull, bear) with user-supplied deltas and optionally builds a 2D sensitivity grid. It also emphasizes that it is a pure calculation with no search, leaving no ambiguity about its primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs that the user supplies deltas and grid values based on their own assessment, and it references dcf_valuation as a comparable tool, suggesting a similar usage pattern. However, it does not explicitly state when to prefer scenario_analysis over other valuation tools like comparables_valuation, so guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, covering the non-mutating and open-ended nature of the search. The description adds the 'domain-restricted Exa search' mechanism and the output of 'authoritative source URLs,' which is useful but does not disclose pagination, rate limits, or edge cases. Given annotation coverage, the description adds moderate behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The primary action and purpose are front-loaded in the first sentence, and the usage guidance is in the second. 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?
There is no output schema, so the description must explain what the tool returns. It mentions 'authoritative source URLs' but does not describe the response structure, whether it returns a single URL or multiple, or how to handle a not-found case. It also lacks any guidance on parameter usage. For a tool meant to be the entry point, this is incomplete and could cause an agent to call it incorrectly or misinterpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per the signal, though the schema itself includes some inline descriptions for date, sector, and companyDomain. The tool description does not reference any parameter or explain how to provide the company name or other fields. It says 'resolve a company name' but does not indicate that the name belongs in the 'company' field of the context object. This is a significant gap since the description should compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Discover'), a resource ('a company's official website, LinkedIn, and registry presence'), and a method ('domain-restricted Exa search'). It also explicitly frames its role as the first step to resolve a company name to authoritative source URLs, clearly distinguishing it from sibling tools that operate on already-resolved companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Use this first to resolve a company name to authoritative source URLs before calling other company tools.' This gives a clear when-to-use directive and implies the correct sequencing, making it unambiguous which tool to invoke initially and why.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description transparently reveals the multi-source fallback strategy and guarantees never returning bare nulls, instead returning a structured not_available status with the checked sources. This is valuable behavioral detail not fully captured by annotations alone, though it does not mention every edge case.
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 structured and information-dense, with each sentence adding meaningful detail about the source order, output format, computed metrics, and fallback behavior. It avoids repetition and fluff, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested context object and no output schema, the description provides sufficient operational context: source priority, default ratio computation, and non-null fallback behavior. It does not explicitly address ambiguous combinations like both 'company' and 'sector' being provided, but the schema enum and descriptions cover most necessary input semantics.
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 descriptions cover about 50% of parameters, and the tool description adds context about output and fallback behavior but not comprehensive per-parameter semantics. It clarifies that 'sector' is for sector-level research and that includeRatios controls inline computation, but parameters like 'company', 'country', and 'listed' lack explicit semantic expansion in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves financial statements and details the source waterfall (screener.in, filing PDFs, HTML, text). It also specifies the output shape (FinancialStatement[] consumed by ratio_analysis) and default inline computation of ratios and CAGR, leaving no ambiguity about the tool's core function.
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 explains what the tool does and its fallback behavior, but it does not explicitly state when to prefer this tool over sibling tools such as ratio_analysis or company_profile. It mentions the same output shape as ratio_analysis but lacks direct guidance on use cases versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the main behavioral aspects. The description adds specific diagnostic areas checked, which provides context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, listing exactly what the health check covers in a single sentence. No fluff or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameters and output schema, the description fully captures the tool's scope and purpose. It clearly enumerates the health aspects checked, leaving no missing context for an agent to invoke it.
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 tool has zero parameters, so the schema is trivially covered. The description does not need to explain parameter semantics, and the baseline of 3 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reporting server health across config validity, Redis, Postgres, and tool registry. It is distinct from sibling tools which focus on data retrieval or report generation.
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 does not explicitly state when to use this tool versus alternatives. Given its diagnostic nature, usage is implied but not directly contrasted with other tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds concrete behavioral specifics: the exact sources searched (SEBI, NCLT, IndianKanoon, LiveLaw, Bar & Bench) and record categories (litigation, penalties, insolvency, disqualification). This goes beyond annotations by detailing the scope of data, which is valuable for an agent deciding if this tool fits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. The first sentence packs the core function and sources, and the second gives a precise contrast with negative_news. Information is front-loaded and every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only research tool with one nested parameter and no output schema, the description covers the essential purpose, sources, record types, and a key sibling distinction. It lacks details about return format or limitations, but openWorldHint already implies non-exhaustiveness. The description is sufficient for an agent to decide whether to invoke it and what input to provide, though it could mention the required company field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate for parameter meaning, but it does not. The only parameter, context, is a nested object with required 'company' and optional fields (date, listed, sector, country, companyDomain). The description never mentions how to specify the subject (e.g., company name in context.company) or what the optional fields do, leaving the agent to infer from the schema alone. Given low coverage, this is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens specific legal/regulatory sources (SEBI, NCLT, IndianKanoon, etc.) for litigation, penalties, insolvency, and disqualification records tied to a company/promoter. It also explicitly differentiates from negative_news, making its purpose unambiguous and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context by naming the sources and record types, and explicitly distinguishes this tool from negative_news for hard legal/regulatory records. However, it doesn't mention when to use it over other relevant siblings like red_flag_screen or promoter_background, leaving some ambiguity for alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool does not forecast, guess, or default inputs, that assumptions are echoed back for auditability, and that structural issues like wacc <= terminalGrowthRate are reported in an issues field. It also states it renders no verdict, aligning with the readOnly and idempotent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and repeats similar caveats multiple times (e.g., does not forecast, does not render a verdict, assumptions are echoed). The core message could be conveyed in fewer sentences without losing important context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of an output schema, the description mentions key output elements: echoed assumptions, an issues field for structural problems, and fairValuePerShare as a non-advice result. It also points to generate_report for the investment thesis, making the surrounding workflow reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents most parameters with meaningful descriptions (e.g., wacc, revenueGrowthPath, incrementalNwcPctRevenueChange). The description adds no further parameter-level detail and leaves some parameters like baseRevenue, taxRate, sharesOutstanding, and companyName without explanatory text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool runs a mechanical, transparent discounted-cash-flow valuation from explicitly supplied assumptions. It names the key inputs and makes the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the caller to supply realistic assumptions reasoned from the company's financials and sector context, and advises pairing the output with an investment thesis rather than treating fair value as advice. It does not explicitly contrast with sibling valuation tools, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no behavioral hints beyond readOnlyHint:false and destructiveHint:false, so the description carries the burden. It discloses the conversion method (headless-browser HTML-to-PDF) and the return mechanism (base64 embedded plus downloadUrl over httpStream), which is valuable. It does not mention any side effects or limitations, but the core behavior is transparent and consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and output details. It avoids redundancy and includes only essential information: what it does, how it does it, and how results are returned. No wasted words, and the structure is logical (action, features, delivery).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return value (base64 PDF plus downloadUrl). It also references generate_report's schema for the input structure, which is necessary for correct invocation. It lacks details on error handling or edge cases, but for a rendering tool that relies on a well-defined input schema, it is sufficiently complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with some parameters documented (tags, brandName, preparedBy, brandTagline, classification). The description adds context by pointing to generate_report's schema for the 'sections' parameter, which helps agents understand the required structure. However, it does not describe the remaining parameters (title, subtitle, companyName, generatedAt) beyond what the schema provides, so it adds limited value for those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: renders a structured report into an institutional-layout PDF with enumerated features (cover page, TOC, headers, footers, page numbers, tables, per-section confidence, citations). It clearly distinguishes from sibling tools like generate_report (which produces the structured data) and generate_markdown (a different output format). The verb 'Renders' plus the output specification make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the input is a structured report from generate_report, indicating this tool is intended to be used after that. It also notes the PDF is returned as a base64 resource for remote clients, implying a specific delivery context. However, it does not explicitly mention alternatives such as generate_institutional_report or generate_markdown, nor when to choose one over the other, leaving some ambiguity among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behavior beyond the sparse annotations (readOnlyHint=false, idempotentHint=true). It reveals the renderer's visual distinction for ai_interpretation sections, the mandatory 'not advice' disclaimer, and the style/voice contract for section writing. No contradiction with annotations — the deterministic assembly described is consistent with idempotentHint=true.
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?
Well front-loaded: purpose first, then usage timing, then metadata behavior, then voice requirements. Every sentence earns its place — the style guidance with anti-pattern examples materially affects output quality. It runs somewhat long (~150 words), but the density of operational guidance justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a complex tool with 10 params and no output schema: it covers purpose, workflow timing, metadata semantics, rendering behavior, and writing style. Gaps are minor — no explicit return-value statement (though the 'report envelope' implies it) and no routing among the report-generating siblings.
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?
With schema coverage at 50%, the description compensates on the most complex parameter: it explains the sections structure (summary, tables, citations, confidence) and the special metadata.kind = 'ai_interpretation' value with its rendering implications. The simpler display parameters (title, subtitle, brandName, classification) are covered by the schema's own descriptions, so the partial coverage gap is acceptable.
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?
States a specific verb and resource: 'Assembles a structured research report from ResearchSections... into the standard report envelope.' The 'does no research of its own' boundary separates it from the research-gathering siblings. However, it does not explicitly distinguish itself from the three report-generation siblings (generate_institutional_report, generate_markdown, generate_pdf), which is a differentiator gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear sequencing: 'Use after gathering facts with other tools; this tool does no research of its own.' This tells the agent when in the workflow to invoke it. However, with three other report-generating siblings present, it offers no routing guidance on when to choose this tool over generate_institutional_report, generate_markdown, or generate_pdf — an explicit exclusion would push this to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the read-only nature, and the description uses 'retrieves' consistently. It adds some behavioral context by listing sources and fallback behavior, but does not disclose details like return format or network/external access beyond what openWorldHint suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose and content are stated first, source list is compact, and usage guidance is separated cleanly. No redundant wording or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a research-retrieval tool, the description gives a strong sense of what will be returned by enumerating content areas and sources. There is no output schema, so the exact response format is not specified, but the intended use and behavior are adequately complete.
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 description adds value by explaining the relationship between context.sector and context.company and the fallback behavior. The schema already provides descriptions for date, sector, company, and companyDomain, and the enum fields are self-explanatory, so the key usage semantics are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves macro/industry-level research and specifies the content areas (market structure, key players, growth drivers, TAM/market size) and source types. It distinguishes this from company-specific research, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives practical guidance to pass context.sector when known and explains the fallback behavior of searching by context.company's industry. It does not explicitly name sibling alternatives or say when not to use it, but the 'company-specific report should sit inside' framing communicates its intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates the tool is non-destructive. The description adds that it queries external regulatory sources (SEBI/MCA/registry), but does not elaborate on rate limits, authentication, or other behavioral aspects. Given the annotation covers the key safety trait, a score of 3 is appropriate.
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, focused sentence that front-loads the action and scope. It avoids unnecessary details and is easy to parse, making it highly efficient for an agent to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter (context) and a nested object, the description adequately covers the tool's purpose and usage. It does not include an output schema, but that is not required for a screening tool, and the description provides enough context for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the context object already explains that context.company should be the promoter/director's name or company name for leadership screening. The tool description reiterates this, ensuring the parameter's meaning is unambiguous. This adds clarity beyond the raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (screens) and the specific resources (SEBI/MCA/registry sources) and the purpose (disqualification, debarment, or regulatory penalty records). It also clarifies that it can take a company name to screen leadership, which distinguishes it from general company search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the user to pass the individual's name (or company name for leadership screening) as context.company, which provides direct usage guidance. It does not mention when not to use it or alternatives, but the instruction is clear and sufficient for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses that missing inputs cause silent omission of a multiple type and reports via an 'issues' field. It also emphasizes deterministic arithmetic, fully aligning with annotations with no contradictions.
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 bit long but each sentence adds distinct value: the first defines the function, the second clarifies inputs and determinism, and the third explains missing-data behavior. It is not excessively redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested schema and no output schema, the description adequately describes the output (valuation bands and blended range) and the issues mechanism. It does not specify exact output fields, but enough context is provided for a basic understanding.
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 only 33%, with descriptions only on peers and target.netDebt. While the tool description explains the roles of the multiples and netDebt, it doesn't clarify all parameters (e.g., sharesOutstanding, companyName, revenue, netProfit) individually. The names are semi-intuitive, but not fully compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool applies peer trading multiples to target financial metrics to derive valuation bands, naming specific multiples and the output. It differentiates from sibling tools like dcf_valuation by focusing on peer-based comparables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to pass real peer figures (e.g., from listed_peer_comparison) and notes that it picks no peers, giving a clear prerequisite and source. While it doesn't explicitly contrast with DCF or other valuation methods, the condition for use is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent, and the description adds 'deterministic' and 'Pure calculation', reinforcing the absence of side effects. It does not describe error handling or output specifics, but with annotations covering the core behavioral traits, the addition is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences that front-load the core purpose and then clarify the calculation nature. No unnecessary words or redundancy, making it easy 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?
The description does not specify the output format or the exact ratios computed, which could be useful for an agent deciding whether this tool meets a need. However, given the tool name and the mention of 'profitability, liquidity, leverage, returns', the intent is reasonably clear, though a brief output summary would improve completeness.
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 statements parameter is well described with 'Chronologically ordered (oldest first) financial statements, e.g. from the financial_statements tool', which adds important context about ordering and source. The optional companyName lacks a description, but it is self-explanatory and not required, so the coverage is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs deterministic financial ratio analysis and multi-period CAGR trends, with a specific verb and resource. It distinguishes itself from siblings by explicitly noting it is a pure calculation tool, not a search or generation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you already have financial statements and need ratio analysis, as evidenced by 'over a set of FinancialStatement objects' and 'Pure calculation — no search'. It does not name alternatives explicitly, but the contrast with search tools is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint and idempotentHint annotations by explicitly stating that the tool 'invents no new evidence' and 'renders no investment verdict.' This provides crucial behavioral context about its non-generative, non-decisive nature, which is not fully covered by the annotations alone.
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 paragraph that is informative but slightly verbose, repeating the idea of 'you've already gathered' and 'pass through' multiple times. It is well-structured and front-loads the main purpose, but could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output format (severity-bucketed flag list with overall severity) and the constraint that flags trace to supplied data. It also clarifies that omitted categories contribute no flags. It does not detail how severity is calculated, but that is likely an internal implementation detail. Given there is no output schema, this level of description is sufficient for an agent to know what to expect.
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 descriptions are provided for 4 of 6 parameters (litigationCases, negativeNewsCount, promoterRegulatoryHits, plausibilityIssuesByPeriod) and are helpful in linking them to source tool outputs. However, companyName and monthsSinceLastFunding lack any description, and the tool description does not clarify them. The 67% coverage is moderate, but the missing explanations for these two parameters leave ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: aggregating evidence from specified sibling tools (litigation_history, negative_news, ratio_analysis/financial_statements, promoter_background) into a severity-bucketed flag list with an overall severity. It distinguishes itself from those source tools and from report generators by focusing on screening and aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (after gathering evidence from the listed tools) and that all inputs are optional, allowing partial usage. It also clarifies that it renders no investment verdict, which helps avoid misuse. However, it does not explicitly contrast with sibling tools like generate_report, leaving some ambiguity about when to prefer this tool over a full report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the data sources and the read-only nature of retrieval, which aligns with the readOnlyHint annotation. However, it does not mention potential limitations like missing data for unlisted companies or possible format variations, leaving some behavioral aspects unspecified.
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, well-structured sentence that efficiently conveys the tool's purpose, data sources, and usage context. There is no redundant information, and the dash separates the core function from the intended usage pattern.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does and why it is used, but it does not specify the output format or structure. Given there is no output schema, this is a minor gap, but the description is sufficient for understanding the tool's role within the peer comparison workflow.
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 provides descriptions for date, sector, country, and companyDomain, but company lacks a description. The tool description adds context that the company should be listed, which indirectly clarifies the 'listed' parameter, but it does not elaborate on the purpose of other fields like sector or country beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving a financial snapshot (market cap, P/E, shareholding pattern) for a single listed company. It distinguishes itself from sibling tools like discover_competitors by focusing on the per-company data retrieval needed for peer comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is 'meant to be run once per company (the target and each peer discover_competitors identifies)' and that results are assembled into a peer-comparison table. This provides clear guidance on when to use this tool relative to competitors discovery and other financial analysis tools.
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

INDUSS Research Intelligence MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![INDUSS Research Intelligence MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/rajyash205/induss-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rajyash205/induss-mcp)

Score Badge

Copy to your README.md:

[![INDUSS Research Intelligence MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/rajyash205/induss-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rajyash205/induss-mcp)

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/rajyash205/induss-mcp'

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