FinBrain MCP

Server Quality Checklist

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

Latest release: v0.2.7
Disambiguation4/5
The by_ticker, screener_, recent_, and available_ prefixes give most tools a clear scope, so the majority are unambiguous. A few pairs like options_put_call vs screener_put_call_ratio and news_by_ticker vs recent_news need closer attention, but the descriptions resolve the intended use.
Naming Consistency4/5
Names mostly follow a consistent pattern of resource plus scope prefix/suffix, such as available_*, *_by_ticker, screener_*, and recent_*. The exceptions are minor but visible: options_put_call lacks a by_ticker suffix, and insider_transactions_by_ticker jumps to screener_insider_trading.
Tool Count3/5
At 33 tools, this server is on the heavy side, largely because most datasets are exposed both as per-ticker endpoints and as screener endpoints. The count is not unreasonable for the broad financial-data domain, but it sits near the limit of what is easy to navigate.
Completeness4/5
The server provides discovery, per-ticker data, recent items, and screeners across a wide array of financial and alternative-data categories. Obvious gaps are minor: there is no screener for corporate lobbying, and a few category axes (market, region, ticker) are not applied uniformly across all tools.
Average 3.1/5 across 33 of 33 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 responsibility for behavioral disclosure. It explains field semantics (e.g., date vs disclosure_date, owner codes, amount flags) and mentions that CSV returns sliced series, but it does not disclose side effects (e.g., read-only), rate limits, pagination behavior, or error handling. The operational behavior remains opaque.
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 front-loads a full JSON schema example before any explanatory text. It is longer than necessary for a tool description, and while it is structured with field explanations, it lacks a concise summary. The detail could be more effectively placed in an output schema if provided.
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 complexity is moderate (nested req object, multiple output fields), and the description provides thorough documentation of output fields, but it omits the tool's core purpose, input parameter guidance, and operational context. It does not clarify that this is a read-only query tool or when to use it, leaving the description incomplete for effective use.
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 input schema includes ticker, limit, format, date_from, date_to, but the description does not explain any of these parameters. It only references CSV vs JSON in one clause ('CSV returns the sliced series') and never addresses the ticker, date bounds, or limit. Schema coverage is effectively zero for most parameters, and the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Normalized US House trades:' followed by a JSON-like structure, but it lacks an explicit verb or statement of what the tool does (e.g., 'Retrieves' or 'Lists'). The purpose is only inferred from the tool name, and the description reads more like a data dictionary than a functional description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like screener_house_trades or senate_trades_by_ticker. No prerequisites, exclusions, or alternative recommendations are provided. The description is entirely about output format, not 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 provided. The description mentions pagination in the output example ('# paged') but does not clarify behavior like rate limits, authentication needs, or whether the tool is read-only. The focus on output format rather than behavioral traits leaves significant gaps.
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 brief but poorly structured, embedding a JSON-like example that may confuse readers. It lacks clear sentences and mixes output format explanation with a representation, making it less concise and harder to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested object schema, multiple parameters, no output schema), the description is completely inadequate. It does not explain the tool's purpose in simple terms, parameter usage, or return behavior, leaving major gaps for an agent to use the tool correctly.
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 adds no information about any parameter. It mentions 'format' only in the output context but does not explain input parameters like 'ticker', 'date_from', 'date_to', or 'limit'. The agent cannot infer parameter semantics from the description.
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 'Normalized LinkedIn metrics' vaguely indicates the tool returns metrics for a ticker, but lacks a specific verb (e.g., 'retrieve' or 'get') and does not differentiate from sibling tools like 'screener_linkedin'.
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. The description does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name and schema 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 provided. The description only shows output structure, not behavioral traits like data freshness, update frequency, or rate limits. Agent lacks critical operational context.
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 short but as a JSON blob it is messy and not front-loaded with a clear action statement. It conveys less than it could in a concise manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and many sibling tools, the description fails to provide complete context. Agent cannot determine what data is returned or how to interpret results reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (ticker, prediction_type, format). It only lists output fields, leaving the meaning and usage of inputs unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a JSON format showing output fields but does not explicitly state that the tool retrieves predictions for a ticker. It is vague and leaves the purpose inferred.
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 the many sibling 'by_ticker' tools. There are no instructions about appropriate contexts or 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?
Without annotations, the description must disclose behavior. It only says 'list', implying a read operation, but provides no details on output format, pagination, or data scope. This leaves significant ambiguity for an agent.
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 extremely concise but underspecified. A single sentence offers no structure, such as parameter descriptions or example usage, which would aid understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a nested parameter, the description is severely incomplete. It fails to explain return behavior, acceptable inputs, or relationship to sibling tools, leaving the agent underinformed.
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 adds no meaning to the parameters. It does not explain 'dataset' values (daily, monthly) or the format parameter, requiring the agent to infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List available tickers for a dataset' which clearly communicates the tool's function. It is specific and distinguishes from sibling tools like 'news_by_ticker' or 'screener_sentiment', but does not explicitly differentiate from 'available_markets' or 'available_regions'.
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. The description lacks context about prerequisites or exclusions, providing no help for an agent to decide between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only shows the output JSON structure and mentions that CSV returns the sliced series. It does not mention read-only nature, rate limits, pagination, or any side effects. This is minimal behavioral transparency for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a compact JSON sample to convey the output format and a single line about CSV behavior. It avoids fluff and is front-loaded with the core concept. The structure is clear and efficient.
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 nested objects and no annotations or output schema, the description should provide more context. It shows the output structure but omits error handling, filtering semantics, and the overall purpose. The schema has parameters that are not elaborated, making it incomplete for an agent to fully understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (the schema itself only describes date formats). The description does not explain the parameters (limit, format, date_from, date_to) or how they affect the output. The output structure is shown but not linked to parameters. No added value over the schema.
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 starts with 'Normalized corporate lobbying filings:' which implies the resource but does not explicitly state the action (e.g., 'retrieves', 'returns'). The name 'corporate_lobbying_by_ticker' is self-explanatory, but the description does not differentiate from other *_by_ticker tools. It provides the output structure but not a clear purpose statement.
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 gives no guidance on when to use this tool versus alternatives. There are many sibling tools with similar patterns, but no mention of criteria for selection, such as 'use this to get lobbying data for a specific ticker' or exclusions. The agent is left 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only status, rate limits, or any side effects. 'Normalized' is ambiguous and not explained.
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 short but includes an output format example that is somewhat useful. However, the structure is messy (JSON embedded in plain text). It could be more concise and better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and low parameter description, the description lacks completeness. It does not explain the meaning of 'normalized', the data granularity (daily? intraday?), or the put_call_ratio calculation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal parameter meaning beyond the schema. The output format example hints at the 'format' and 'limit' parameters but does not clarify the others like 'ticker' or date ranges.
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 states 'Normalized options put/call time series,' which conveys the resource but lacks a specific verb (e.g., 'retrieves' or 'lists'). It does not differentiate from sibling tools like 'screener_put_call_ratio' or other time-series tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or when not to use it. The description does not help the agent decide between this and similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only shows the response structure but does not mention that the tool is read-only, any rate limits, side effects, or required permissions. The 'normalized' label hints at data processing but lacks explicit transparency.
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 fairly concise at a few lines but includes a verbose JSON structure that might clutter. It front-loads the concept of 'normalized analyst ratings' but then dumps details that could be in the output schema. Acceptable but not optimal.
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 (5 parameters, nested objects, no output schema) and 29 sibling tools, the description is insufficient. It does not explain the meaning of rating types, signals, or how CSV slice works. Missing details on pagination, defaults, or how to interpret the data, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions for most fields), so the description must compensate. It provides the output structure which indirectly explains the meaning of some parameters (e.g., date range via series), but does not describe the required 'ticker' parameter or the effect of 'limit' and 'format'. The output schema is missing, so the agent must infer parameter usage from the response example.
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 it provides 'Normalized analyst ratings' and shows the expected JSON structure with fields like ticker, name, series, and rating details. This makes the primary function clear. However, it does not differentiate itself from sibling tools like 'recent_analyst_ratings' or 'screener_analyst_ratings', which slightly reduces clarity.
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 its many siblings. The description only mentions the output format without explaining the context or prerequisites (e.g., ticker is required). There is no mention of when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only mentions paging, not whether the operation is read-only, any authentication requirements, rate limits, or mutability. The format spec implies read operation but not explicitly.
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 very short but includes a full JSON schema and CSV example, which is verbose and not typical for a tool description. It is not front-loaded; the key purpose is stated first, but the bulk is a raw format dump.
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, the description covers the core purpose and provides return format details (since no output schema). However, it omits context like typical use cases, data freshness, or how paging works in practice.
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 context indicates 0% schema description coverage, meaning the description must compensate. It does not explain any parameters beyond the implicit 'ticker'. The JSON/CSV format shows output structure but not input semantics. The schema itself provides descriptions for each parameter, but the description adds no value.
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 tool name app_ratings_by_ticker combined with 'Normalized app ratings' clearly indicates it retrieves app store ratings for a given ticker. The mention of paging over 'series' hints at the data structure. However, the term 'normalized' is not explained and may confuse some agents.
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 screener_app_ratings or other by_ticker tools. There is no mention of prerequisites, context, or exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authentication requirements, rate limits, or data latency. The only information is the return format, which is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a verbose JSON example block that repeats schema information (format field) and adds output structure, but lacks conciseness. It is front-loaded with a clear purpose sentence, but the example could be more succinct or better formatted.
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 nested input schema, the description should explain required parameters, defaults, and the 'req' wrapper. It only shows an example return format without clarifying the input structure or behavior, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters wrapped in a nested 'req' object, but the description does not explain any of them. The JSON example in the description shows output fields, not input. Schema description coverage is 0%, and the description adds minimal value 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 tool provides 'Reddit mention counts across subreddits for a single ticker', specifying the verb (counts) and resource (mentions). However, it does not distinguish this tool from the sibling 'screener_reddit_mentions', which likely aggregates across tickers.
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 on when to use this tool versus alternatives (e.g., screener_reddit_mentions) or when not to use it. The description lacks any contextual usage advice.
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, and the description adds minimal behavioral context beyond the output format ('flat rows with expected_* percentages'). It does not address side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. It is front-loaded and to the point, but could include more detail without becoming verbose.
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, and the presence of many sibling tools, the description is incomplete. It does not differentiate from predictions_by_ticker or other screener tools, nor explain expected return structure or parameter effects.
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?
Despite 0% schema description coverage, the description only explains two of five parameters (market and region). It omits prediction_type, limit, and format, which are important for correct 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 indicates that the tool provides screener-based market predictions with expected_* percentages, and can be filtered by market name or region. This distinguishes it from ticker-level tools like predictions_by_ticker and other screener tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filtering by market or region but provides no guidance on when to use this tool versus alternatives, nor does it specify 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits beyond returned fields. Missing info on data freshness, rate limits, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, direct sentences with no extraneous information. Efficiently communicates core function and output.
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 nested input schema and no output schema or annotations, the description is too brief. It lacks detail on output behavior, use cases, and does not compensate for missing structural metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value. It lists result fields but does not deepen understanding of parameters beyond what the schema provides.
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 it screens news across tickers and lists returned fields. It distinguishes from sibling tools like 'news_by_ticker' by implying multi-ticker scope, but could be more explicit about differentiation.
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 like 'news_by_ticker' or 'recent_news'. With many sibling tools, explicit usage context is missing.
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 responsibility. It mentions 'paging over series' and output formats (JSON/CSV), but does not explain how paging works, the effect of parameters like limit or date filters, or any constraints. This lacks depth for an operation that mutates nothing but likely has pagination nuances.
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 and front-loaded with the key purpose. The included JSON and CSV structure is useful given the lack of an output schema, serving as a de facto output specification. It is efficient without redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested parameters and no output schema, so the description's output structure is valuable. However, it omits how pagination is performed, how limit interacts with series_total, and how date filters work. This leaves gaps for an agent to correctly invoke the tool without additional 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?
Schema description coverage is 0% and the description does not compensate. It lists ticker and name in the output structure but does not explain input parameters like limit, date_from, or date_to beyond what the schema already provides (e.g., date format). The mention of 'format' in the JSON snippet hints at output format but not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that it returns 'normalized insider transactions' with paging, which clearly identifies the resource and action. It is distinguishable from siblings like house_trades_by_ticker and senate_trades_by_ticker by the specific domain 'insider transactions' in the name and description, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 similar ticker-based tools (e.g., house_trades_by_ticker, analyst_ratings_by_ticker). The description only states what it returns, not when it should be preferred over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially shoulders the burden. It reveals the response format and mentions pagination ('paged'), but omits details like rate limits, authentication requirements, or any side effects. It adequately describes the output shape but not operational 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 short and includes a JSON-like block for the response format. It is front-loaded with 'Returns normalized sentiment'. While the code block is compact, it could be more readable as prose. Overall, it is efficient but not perfectly 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 complexity (5 parameters, nested objects, no output schema), the description is incomplete. It does not clarify the sentiment score range, pagination details, or how this tool differs from sibling tools like news_by_ticker or sentiment screeners. Lacks sufficient context for full 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?
Schema description coverage is 0%, but the description does not explain parameters beyond showing the response structure. It does not describe ticker, date_from, date_to, or limit. The schema itself has minimal descriptions (e.g., YYYY-MM-DD for dates). The description adds little to 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 it returns normalized sentiment and outlines the response structure including ticker, name, series, and format options. This distinguishes it from sibling tools like news_by_ticker (news articles) and sentiment screeners by focusing on per-ticker sentiment data. However, it does not explicitly contrast with these siblings.
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 news_by_ticker or screener_sentiment. It lacks any context about prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry all behavioral context. It mentions the response format but does not disclose rate limits, read-only nature, data source freshness, or any side effects. It also doesn't explain what constitutes a valid ticker or how date filtering works. The only behavior implied is that it returns patent data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then provides a detailed JSON response structure. It's concise in wording, but the embedded JSON is extensive. However, it's a compact representation of the response, which is useful. Overall, it's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects and no output schema, but the description provides an inline representation of the response structure, which gives significant context. However, it lacks information on typical use cases, edge cases (e.g., empty results), validation requirements for ticker, and the meaning of fields like CPY or CIK. Given the moderate complexity, the description is partially incomplete.
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 description does not explain any of the input parameters (ticker, limit, format, date_from, date_to). The schema itself has minimal descriptions (only 'YYYY-MM-DD' for dates). The description only notes that CSV returns the sliced `series`, which is output-related, not parameter semantics. With 0% schema description coverage, the description should compensate but does not.
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 USPTO granted patents mapped to a single ticker by corporate assignee. This distinguishes it from other `_by_ticker` tools (e.g., analyst_ratings_by_ticker) and the response format confirms it returns patent records. The name itself is also explicit.
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 usage guidance is provided. The description only states what the tool does and the response structure, but does not mention when to use it, when not to, or alternatives. For instance, it doesn't clarify that it's specific to patents or that it requires a valid ticker.
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 provided, so description carries full burden. Only states return fields; no disclosure of data freshness, pagination, rate limits, or side effects. Lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first for purpose, second for returned columns. Highly concise and front-loaded with essential information, no extraneous 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?
Provides return columns (no output schema), but lacks parameter explanations, usage guidelines, and behavioral traits. Incomplete for a tool with nested parameters and no annotations.
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%. Description does not mention any parameters (market, region, limit, format) despite having 4 parameters. Fails to add meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Get the most recent analyst ratings across all tracked stocks' with a clear verb and resource, and lists returned columns. It distinguishes from sibling tools like 'analyst_ratings_by_ticker' by specifying 'across all stocks'.
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. Does not mention that for specific tickers the sibling 'analyst_ratings_by_ticker' should be used, nor any exclusion criteria.
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; description only lists output fields. No mention of behavior like pagination, rate limits, or how market/region filtering works, leaving significant gaps for a screener tool.
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?
Two sentences, efficient and front-loaded. However, could be structured with bullet points or separate sections for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested parameters and many siblings, the description is too brief. No output schema, so return format (beyond field list) is missing; lacks explanation of screening logic or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for market, region, limit, format. The description adds no parameter-specific meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Screen analyst ratings across tickers' with specific output fields, but does not differentiate from sibling screener tools like screener_app_ratings or screener_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?
No guidance on when to use this tool versus alternatives (e.g., analyst_ratings_by_ticker, recent_analyst_ratings). The description implies broad screening but lacks 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?
With no annotations, the description must disclose behavior itself. It explains output semantics (date lag, owner codes, amount normalization) and the CSV behavior, but omits operational details like rate limits, authentication, or pagination. It does not contradict annotations but is incomplete on behavioral traits.
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 quite long and dives deep into output field semantics, which is useful given no output schema, but it lacks a front-loaded summary. It spends many sentences on edge cases (amount_flag, owner) that could be condensed without losing essential guidance.
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 rich output structure and absence of an output schema, the description adequately documents the returned data. However, it overlooks practical context such as how to use the 'limit' parameter, whether results are paginated, or the meaning of the series object. Overall, it is more complete on output than on usage 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 explain the key parameters (ticker, limit, date_from, date_to) beyond the schema's minimal date descriptions. It mentions 'format' in the output sample but not as a parameter choice. Schema coverage is low, so the description should compensate, but it focuses on output fields instead.
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 it returns normalized US Senate trades, with a specific resource (ticker) and verb implied by the data structure. It distinguishes from siblings like house_trades_by_ticker via the name itself, though the description does not explicitly call out alternatives.
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 (e.g., house_trades_by_ticker or screener tools). It does not mention prerequisites, use cases, or exclusions, leaving the agent to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return structure in detail, including the JSON fields and the CSV behavior ('CSV returns the sliced `series`'), which is valuable. However, it does not disclose error behavior, rate limits, or how pagination and date filtering behave beyond what the schema implies.
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 front-loads the purpose in a single line, then provides a structured JSON output example. Although the JSON block is lengthy, it is directly informative for understanding the response shape. No redundant prose is present; it is efficient for what it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-ticker data tool with five nested parameters and no output schema, the description provides a detailed return structure, which is helpful. However, it omits parameter usage and any when-to-use context, making it moderately complete but not fully self-sufficient for an agent deciding how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate but does not. It never explains the parameters (ticker, limit, format, date_from, date_to) except incidentally showing 'format' in the output spec, which could be confused with a parameter. The schema provides some basics (e.g., date format, limits), but the description adds no semantic value.
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 'U.S. government contract awards for a single ticker', which identifies the tool's purpose and distinguishes it from the sibling screener_government_contracts (which is likely for multiple tickers). However, it lacks an explicit verb like 'get' or 'retrieve', making it a noun phrase rather than an action-oriented statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Although the phrase 'for a single ticker' implies a use case, the description does not mention the sibling 'screener_government_contracts' or explain when to choose one over the other. This leaves the agent to infer 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?
With no annotations, the description carries the behavioral burden. It explains the response structure (JSON/CSV, paged series) and the format parameter. However, it omits details like pagination mechanics, ordering, rate limits, or authentication requirements.
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 moderately concise but includes a verbose JSON example that is not well-formatted (all on one line). The main purpose is front-loaded, but the inline JSON could be cleaner or referenced to a schema.
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 output schema, the description provides the response structure. However, it misses pagination details, default limit, and ordering. It is adequate but not fully comprehensive for a tool with 5 parameters and no annotations.
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 coverage is 0%, meaning no parameter descriptions exist. The description only mentions 'format' and gives a vague 'YYYY-MM-DD' hint in schema for dates. It does not explain 'ticker' (required), 'date_from', 'date_to', or 'limit'. The agent gets no parameter understanding from 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 returns recent news articles for a ticker and distinguishes it from sibling tools like 'news_sentiment_by_ticker' and 'recent_news' by specifying the exact resource (news articles) and verb (returns). The response format is also detailed.
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 explicit guidance on when to use this tool versus alternatives. The sibling list includes many news-related tools (e.g., 'recent_news', 'news_sentiment_by_ticker') but the description does not explain when to choose this one. The agent must infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description says it returns rows with specific fields but does not mention side effects, data freshness, pagination, or prerequisites. It is partially transparent but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists output. Front-loaded and concise, though could be more terse.
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?
No output schema, but description lists output fields. However, it does not explain how to use nested parameters (req object) nor any limitations. Incomplete given the parameter complexity.
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 coverage is 0% and the description does not explain any parameters (market, region, limit, format). The schema has minimal descriptions (e.g., 'e.g., S&P 500'), but the tool description adds no value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get' and resource 'most recent news articles across all tracked stocks', and lists output columns. Distinguishes from sibling tools like news_by_ticker by 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 on when to use this tool vs alternatives such as news_by_ticker or screener_news. The description implies it is for a broad overview, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It is a simple read operation with no parameters, but the description does not mention any behavioral traits such as data freshness, error handling, or whether the list is comprehensive. However, given the simplicity, the lack of behavioral detail is acceptable but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the key information. For a simple tool, this is appropriately 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?
The tool has no parameters and an output schema exists, so the description does not need to detail return values. However, it could be more complete by explaining that the output is a list of market identifiers or names, or indicating that this is a prerequisite for other market-based queries. The example helps but is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema). The description does not add parameter information, which is acceptable since there are none. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available markets (e.g., 'S&P 500')' clearly states the action (list) and the resource (markets). It provides an example, making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'available_regions' or 'available_tickers', but the context implies it is for markets specifically.
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. The sibling tools list many ticker-specific tools, but the description does not indicate that this tool should be used to discover market options before querying other tools that require a market parameter.
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, and the description does not disclose any behavioral traits such as rate limits, authentication requirements, or side effects. It only describes the output, leaving significant gaps for an agent.
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 core purpose, followed by the output columns. Every word is necessary, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides the return fields (ticker, name, date, put_call_ratio, call_count, put_count), which is helpful. It does not explain pagination or limits, but the schema contains that info. Overall, adequate for a straightforward screener.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters (market, region, limit, format). The tool description adds no additional parameter meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Screen put/call ratio across tickers' and lists the return fields, making the tool's purpose highly specific and unambiguous. The name reinforces this purpose, and it is distinct from sibling screener tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. While it is implied that this tool is for put/call ratio screening, there is no explicit mention of when not to use it or which sibling tool would be appropriate for other metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It indicates the tool returns rows with specific fields but does not disclose read-only nature, rate limits, or other behavioral traits beyond output format.
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: first defines action, second lists output columns. No wasted words, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a screening tool with one nested parameter and no output schema, the description is adequate but lacks details on pagination, limit behavior, and any filtering constraints beyond the minimalist schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond listing output fields. The parameter descriptions in the schema already cover limit and format, and the tool description does not enhance understanding of input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens insider trades across all tickers and lists the output columns, making its purpose unmistakable and distinguishing it from other screener siblings.
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 insider_transactions_by_ticker or other screener tools, leaving the agent to infer appropriate usage.
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 provided; description does not disclose behavioral traits such as read-readiness, rate limits, or data staleness. It only states what is returned, missing safety or side-effect context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: first states purpose, second lists output fields. Highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes output rows and summary but does not explain how parameters like market/region affect behavior. For a nested-object screener, more context on filtering semantics would be helpful, but no output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning to parameters beyond schema descriptions. Baseline score 3 is appropriate as the description repeats output details but not parameter context.
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 'Screen Reddit mentions across tickers,' which is a specific verb and resource. It distinguishes from sibling 'reddit_mentions_by_ticker' by indicating cross-ticker screening vs. single-ticker retrieval.
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 vs. alternatives like 'reddit_mentions_by_ticker'. The name implies screening across tickers but the description does not provide when-not or alternative tool references.
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 provided. The description does not disclose if the tool is read-only, any side effects, rate limits, or authentication requirements. It only lists return fields.
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 tool's purpose, and provides necessary detail without excess. Every sentence is useful.
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?
Despite lack of output schema, the description explains return values (rows and summary). The tool is simple with two parameters, and the description is mostly sufficient, though it could add usage context vs siblings.
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?
Input schema covers both parameters (limit and format) thoroughly. The description adds no additional semantics beyond what the schema provides. Baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it screens U.S. government contract awards across all tickers, and lists the returned fields. It distinguishes from the sibling 'government_contracts_by_ticker' which is for individual tickers.
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 says 'across all tickers' implying no ticker filter, but does not explicitly state when to use vs alternatives like government_contracts_by_ticker or other screener tools. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses output fields and nullable columns (owner and disclosure_date) with rationale, which is useful. However, it does not mention pagination, rate limits, or whether data is current or delayed, leaving gaps for behavioral insight.
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 concise two-sentence paragraph that front-loads the primary function and then details output columns. It is dense with relevant information and avoids redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (one parameter, no output schema), the description covers the purpose and output fields. However, it lacks guidance on pagination or how to handle large result sets, and it doesn't mention any potential performance implications for the 20000 limit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents 'limit' and 'format' with defaults and ranges. The description adds context by listing output fields implied by the tool's purposeasmaior, but it does not describe parameter semantics beyond the schema. Baseline 3 plus slight credit for output field clarification.
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 that the tool screens House of Representatives trades and enumerates the returned fields. It distinguishes from 'house_trades_by_ticker' and 'screener_senate_trades' by specifying it is a screener for House trades, though it doesn't explicitly differentiate from the by_ticker 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?
The description implies usage for screening trades across all tickers, and the schema's req description says 'no market/region filter'. However, it does not explicitly state when to prefer this over 'house_trades_by_ticker' (e.g., when no ticker filter is needed) or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return structure and input requirement. However, it lacks details on the meaning of the score, error handling, rate limits, or any destructive implications (none expected). The transparency is adequate but not comprehensive.
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-loads the purpose, and contains no unnecessary words. Every sentence adds value: purpose, return structure, and requirement.
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 nested input schema, no output schema, and no annotations, the description provides the essential inputs and outputs but lacks explanation of the score scale, pagination behavior, or how to differentiate from similar screener tools. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for all parameters. The description reinforces that market or region is required and lists return fields, but does not add significant new meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'screen', the resource 'sentiment across tickers', and the scope 'by market or region'. It distinguishes from sibling screener tools (e.g., screener_news) by focusing on sentiment. The return fields are listed.
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?
It provides a clear requirement ('Either market or region is required') but does not explicitly state when to use this tool versus alternatives like news_sentiment_by_ticker or other screener tools. The context is implied by the name but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns rows with specific fields (ticker, name, date, app_store_score, play_store_score) and that either market or region is required. It does not mention any destructive actions, rate limits, or pagination, but it is adequate for a read-only screener.
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 no wasted words. It front-loads the purpose and then gives essential details on outputs and requirements. Every sentence contributes meaningfully.
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 no output schema, the description adequately lists the returned columns. It covers the core functionality and the critical requirement. It could be more complete by explaining the meaning of scores or ordering, but for a simple screener it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by listing return columns and reinforcing the requirement for market or region, but does not significantly expand on the parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Screen app ratings across tickers by market or region', with specific returned fields. It distinguishes from sibling tools like 'app_ratings_by_ticker' by indicating a broader scope across tickers and requiring market or region.
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 specifies that either market or region is required, giving clear context for usage. However, it does not explicitly state when to use this tool versus alternatives (e.g., app_ratings_by_ticker for a single ticker), so guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states a read operation ('List') but lacks details on rate limits, authentication, or any side effects. This is insufficient for an agent to understand risks.
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 only two sentences, both essential. The first provides the core function, and the second adds critical usage context. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (0 parameters, no output schema), the description covers the main purpose and a usage hint. It is complete enough for an agent to decide when to call this tool. Missing behavioral details reduce 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 tool has zero parameters, and the schema coverage is 100% (no params). According to guidelines, baseline is 4. The description does not need to add parameter info, and it fulfills the requirement.
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 verb 'List' and the resource 'markets grouped by region', distinguishing it from siblings like available_markets and available_tickers. It provides a specific and unambiguous 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 hints at a key use case: 'Use region codes for filtering in other endpoints', which guides when to use this tool. However, it does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries burden. It details return fields and summary stats but does not disclose read-only nature, authentication needs, or rate limits. Adequate but not comprehensive.
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: first states purpose, second lists output. No redundant information, front-loaded, and every sentence 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 tool with one nested parameter and no output schema, the description compensates by listing all return fields and aggregate stats. Could mention limit/format usage, but schema covers that. Nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both limit and format described. Description adds no additional parameter context beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens USPTO granted patents across all tickers, with specific verb and resource. It distinguishes from sibling patent_filings_by_ticker which is per-ticker, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for broad screening by saying 'across all tickers', contrasting with per-ticker siblings, but does not explicitly state when to use or avoid alternatives. Context provides enough hint for an agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that owner and disclosure_date are nullable and that historical rows were backfilled upstream, which is useful. However, it does not mention pagination, rate limits, or the meaning of the 'req' object beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It efficiently lists return fields and notes nullability without unnecessary detail.
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 tool's simplicity (one parameter, no output schema), the description is fairly complete. It explains the return fields and nullability. It could mention that the tool returns all tickers without filtering, but that is implied by the name and sibling 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?
Schema description coverage is 100%, so the schema already documents the 'req' object with limit and format. The description adds context about the returned fields but does not add parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens Senate trades across all tickers, listing the returned fields. It distinguishes itself from sibling tools like senate_trades_by_ticker by explicitly covering all tickers, and from screener_house_trades by specifying Senate trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for screening Senate trades across all tickers, which differentiates it from per-ticker tools. It does not explicitly state when not to use it or name alternatives, but the context is clear given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states it returns rows with specific columns and that one of market/region is required, but does not disclose pagination, rate limits, or whether it is read-only. It provides minimal but sufficient context for a screening 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?
Two concise sentences: first states the purpose, second details the output and required input. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description helpfully lists return columns. However, it does not mention optional parameters like limit and format (present in schema), nor clarify if market and region can be combined. Still, it covers the core behavior adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters described. The description adds value by listing the output columns (ticker, name, date, etc.) and reinforcing that market or region is required, which goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Screen LinkedIn data across tickers by market or region,' with a specific verb and resource. It distinguishes from sibling screener tools (e.g., screener_analyst_ratings) and from the per-ticker linkedin_metrics_by_ticker.
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 indicates that 'Either market or region is required,' guiding on required inputs. However, it does not explicitly state when to use this tool over alternatives like linkedin_metrics_by_ticker or other screeners.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behavioral traits: no network call, tries to resolve API key, and returns versions. Could add error handling info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no wasted words.
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 no parameters and an output schema, the description fully covers the tool's behavior and purpose.
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?
No parameters, baseline score of 4 is appropriate; description adds no parameter info but it's not needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns 'Basic server health & version info', which is specific and distinguishes it from data retrieval 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?
It mentions the context (no network call, resolves API key) but doesn't explicitly state when not to use or alternatives; however, the unique intent is clear.
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:

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

Score Badge

Copy to your README.md:

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

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