Veroq

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation3/5
Many tools have overlapping purposes, e.g., multiple ticker analysis tools (veroq_ticker_price, veroq_ticker_analysis, veroq_ticker_score, veroq_full, veroq_fast_snapshot) and multiple search tools (veroq_search, veroq_web_search, veroq_ask). Descriptions help but ambiguity remains.
Naming Consistency4/5
Most tools follow a consistent 'veroq_verb_noun' pattern (e.g., veroq_get_report, veroq_run_agent). There are minor deviations like 'veroq_agent_packs' and 'veroq_fast_heatmap' but overall predictable.
Tool Count2/5
78 tools is excessive for an MCP server. Many are niche (travel, GitHub, Hacker News) and could be consolidated. The server would benefit from reducing tangential features.
Completeness4/5
The tool set covers a wide range of financial data: prices, fundamentals, technicals, sentiment, news, insider, filings, macro, and more. Fact-checking and research tools add depth. Minor gaps like lack of portfolio management are acceptable.
Average 4.4/5 across 78 of 78 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the return type and cost, but lacks details on data update frequency (weekly), error conditions, or any behavioral nuances. 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?
Exceptionally concise and well-structured with clear sections: purpose, when to use, returns, cost, and example. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides sufficient context: it states the return fields (net positions, open interest, changes) and cost. Slightly lacking in specifying data frequency (weekly) but still fairly complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a description listing examples. The tool description only adds an example call with 'gold', which is already implied by the schema. Minimal added 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 it provides CFTC Commitment of Traders positioning for a commodity, with specific output details. While not explicitly differentiating from sibling tools like veroq_commodities, the purpose is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a 'WHEN TO USE' section that explains the tool's utility for viewing futures market positioning and notes its role as a contrarian indicator. However, it lacks explicit when-not-to-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but the description discloses key behaviors: paywall handling, return format with truncation, credit cost, and max URL constraint. It lacks details on error handling but covers the main expectations.
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?
Exceptionally well-structured with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE, CONSTRAINTS). Every sentence adds value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description specifies return fields (title, domain, word count, truncated text) and constraints (max 5 URLs, cost). It is adequate for most use cases, though missing error scenarios.
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 provides an example format ('urls' as comma-separated) and reiterates constraints, but adds no new meaning 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?
Clear verb and resource: 'Extract article content from URLs'. Specific and not a tautology. However, it does not explicitly distinguish from sibling tools like 'veroq_crawl', but given the context, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' section provides context (analysis of full text). However, it does not mention when not to use or suggest alternative tools, limiting guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a list of papers with specific fields and mentions a cost of 1 credit. However, it does not explain whether the tool modifies data, authentication requirements, rate limits, or any side effects. For a simple read operation, the description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear opening line, followed by structured sections (WHEN TO USE, RETURNS, COST, EXAMPLE). However, the EXAMPLE is an empty object '{}', which adds little value; it could be omitted or replaced with a realistic example. Overall, it is well-organized and focused.
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 simple nature of the tool (no parameters, no output schema), the description explains the output fields but omits details like pagination, result count, sorting, or update frequency. Users might need to know if results are limited or how to get older papers. The description is functional but lacks some 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 no parameters, and the input schema is empty with 100% schema description coverage. The description does not need to add parameter documentation, and per guidelines, a baseline of 4 is appropriate. The description does not add unnecessary details about 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 states 'Latest arXiv AI/ML research papers' and specifies 'returns list of papers with title, authors, abstract, categories, and arXiv URL'. It clearly identifies the tool as providing recent AI/ML academic papers from arXiv, which distinguishes it from siblings like 'veroq_research' and 'veroq_research_github' that cover different research domains.
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 includes an explicit 'WHEN TO USE' section stating 'To discover recent academic research in artificial intelligence and machine learning. Good for tracking cutting-edge developments.' However, it lacks guidance on when not to use this tool or alternatives for related tasks (e.g., if the user needs non-AI papers or different filtering criteria).
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 full burden. It states costs (2 credits) and returns (headline, scores, analysis, synthesis), implying a read-only operation. However, it does not explicitly state non-destructive behavior or disclose any side effects beyond the output.
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 efficient: 4 sentences plus an example. It front-loads purpose, then usage, returns, cost, and example. No redundant information; each section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description adequately covers purpose, usage, return structure (headline, scores, analysis, synthesis), and cost. It lacks details on the number of sources or bias score interpretation but is sufficient for an agent to decide and invoke.
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 one parameter 'topic' described. The description adds an example ('Federal Reserve rate decision') which reinforces usage but does not add meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares how different news sources cover the same topic with bias analysis and synthesis. It distinctively differentiates from sibling tools like veroq_ticker_news or veroq_feed by focusing on multi-source comparison rather than single-source news.
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 'WHEN TO USE' section explicitly states the use case: understand media bias or see coverage differences across outlets. It does not mention when not to use or alternatives, but the sibling list shows no direct competitor, making this guidance clear enough.
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 cost (2 credits), return values, and an example. However, it does not mention error behavior, data freshness, or required authentication. For a read-only retrieval tool, this is adequate but not exceptional.
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 very concise: a single sentence for purpose, followed by clearly labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Each sentence adds value and is front-loaded. 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 the simplicity of the tool (one parameter, no output schema), the description fully covers purpose, usage context, return values, cost, and an example. The agent has enough information to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'symbol' with a clear description and examples. The description adds an example ({'symbol': 'NVDA'}) which reinforces usage but does not add new semantic meaning beyond the schema. With 100% schema coverage, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is clearly stated: 'Get next earnings date, EPS estimates, and revenue estimates for a stock ticker.' The verb 'Get' and specific resources (earnings date, EPS, revenue) make it clear. While no explicit sibling differentiation is in the description, the tool's focus on earnings distinguishes it from siblings like veroq_ticker_price or veroq_ticker_analysis.
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 includes a 'WHEN TO USE' section: 'To check when a company reports earnings and what the Street expects. Useful before earnings season.' This provides clear context for usage. However, it does not mention when not to use or provide alternatives, hence a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'pre-computed' and a credit cost, but lacks details on authentication, rate limits, failure modes, or update frequency. While it states 'RETURNS: Structured macro data', it does not elaborate on the structure or behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear headings (WHEN TO USE, RETURNS, COST, EXAMPLE). Each sentence adds value, and the content is front-loaded. No wasted text.
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 has no parameters and no output schema, the description adequately covers what data is returned (yields, CFTC, jobs, energy). However, it could be more complete by specifying data sources, update frequency, or format examples beyond the empty example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100% trivially. The description adds no parameter information, which is acceptable. Baseline score of 4 applies.
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 a macro snapshot combining treasury yields, CFTC positioning, jobs, and energy prices, using specific verbs like 'combining' and 'snapshot'. However, it does not explicitly distinguish itself from sibling tools like 'veroq_economy' or 'veroq_energy_overview', which may have overlapping data.
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 'WHEN TO USE' section explicitly describes the use case: a single-call macro snapshot. It provides clear guidance on when to invoke this tool. It does not mention when not to use it or alternatives, but the context is sufficient for a simple zero-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses return fields, cost (2 credits), and constraints (max 90 days, max 100 results), adding value beyond the schema. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (WHEN TO USE, RETURNS, COST, EXAMPLE, CONSTRAINTS) and no unnecessary words. It is concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 2 well-documented parameters, the description covers purpose, usage, returns, cost, example, and constraints. It lacks details on ordering or pagination but is sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds an example call and clarifies constraints (e.g., 'max 90 days'), providing practical context 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 'Get upcoming and recent IPOs from SEC EDGAR S-1 filings,' specifying the verb, resource, and source. It distinguishes from general EDGAR filings but does not explicitly differentiate from sibling tools like veroq_earnings or veroq_edgar_filings.
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 'WHEN TO USE' section says 'To track the IPO pipeline and recent public offerings,' which provides context. However, it does not mention when not to use this tool or suggest alternatives, leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it returns a list of regulations with fields and mentions a cost of 1 credit, but does not disclose any behavioral traits such as rate limits, destructive actions, or permission requirements. The description is minimal on 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 well-structured with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE) and is concise. However, the EXAMPLE is empty, which slightly reduces effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately explains what it returns and when to use it. It could benefit from specifying the time range or if all regulations are returned, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter documentation is needed. Baseline score of 4 is appropriate as the description does not need to add parameter info.
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 provides 'New Federal Register regulations — proposed and final rules', differentiating it from sibling research tools like veroq_research_bills and veroq_research_fda by focusing on federal regulations.
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 'WHEN TO USE' section explicitly states it is for tracking new federal regulations affecting industries, for compliance and risk analysis. It does not mention when not to use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the cost (2 credits) and return fields (price, change, change percent, unit). However, it does not mention authentication requirements, rate limits, or data freshness, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences plus labeled sections) and well-structured with WHEN, RETURNS, COST, EXAMPLE. It front-loads the key purpose but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single optional parameter, no output schema, one sibling set), the description fully covers usage, return values, cost, and an example. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'symbol' is already fully described in the input schema with examples. The description reiterates this info without adding new semantic meaning, so baseline score of 3 is appropriate 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 retrieves commodity prices for a list of specific commodities (gold, silver, oil, etc.) and distinguishes behavior between no argument (returns all) and passing a slug (single commodity). This differentiates it from sibling tools like 'veroq_crypto' or 'veroq_forex'.
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 'WHEN TO USE' section explicitly states the tool is for commodity market data covering precious metals, energy, and industrial commodities. While it does not list exclusions or direct alternatives, the context is clear enough for an agent to decide.
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 full burden. It discloses cost (2 credits) and return format, but omits details like read-only nature, error handling, or side effects, which is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Slight redundancy between the top sentence and RETURNS, but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description fully explains return values (field-level changes, sources) and usage context. No missing pieces given the low complexity.
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 limited value beyond the schema. The example provides format context, but parameters are already well-documented with descriptions and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get a diff of changes to a living brief' and specifies the resource. It distinguishes from siblings like veroq_brief and veroq_compare by focusing on changes over time.
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 'WHEN TO USE' section explicitly tells agents to use this tool for seeing changes since a timestamp and requires a brief ID. However, it does not specify when not to use or mention alternatives, leaving some ambiguity.
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 relies on text. It discloses the cost (1 credit) and return content (financial data), but does not mention any limitations, state changes, or auth needs. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence adds value, and the structure aids quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose, usage, cost, and an example. It lacks details on date ranges or formatting but is generally complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'ticker' parameter. The description provides an example but adds minimal extra meaning beyond the schema, meeting the baseline for full 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 identifies the tool as providing XBRL financial data (income statement, balance sheet, cash flow) from SEC EDGAR, differentiating it from siblings like 'edgar_filings' (raw filings) and 'edgar_insider' (insider transactions).
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 'WHEN TO USE' section explicitly states the tool is for getting structured financial statements from SEC filings, providing clear context. It does not mention when not to use or alternative tools, but the context is sufficient for selection.
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 cover behavioral traits. It mentions cost (2 credits) and return structure, but omits details like rate limits, pagination, or authentication requirements. The description is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (WHEN TO USE, RETURNS, COST, EXAMPLE). It is concise, front-loaded, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description describes the return format in detail. However, it lacks information on ordering, result limits, and authentication. For a tool of this complexity, it is mostly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for both parameters. The description adds an example but does not provide additional semantics beyond what the schema offers. Thus, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get notable events detected across intelligence briefs — significant developments, announcements, and inflection points.' It uses specific verb and resource, and the distinction from siblings is evident as it focuses on events rather than raw news or market data.
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 'WHEN TO USE' section provides clear guidance: 'To discover major events like product launches, policy changes, or market-moving announcements. Filter by type or subject.' It includes an example but lacks explicit when-not-to-use or alternative tool references, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool consumes 2 credits and returns specific data, but it lacks details on update frequency, limitations, or any side effects. It mentions data source (13F filings) partially.
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 highly concise with separate sections for summary, when to use, returns, cost, and example. Every sentence is useful and earns its place, with 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?
For a simple single-parameter tool without output schema, the description adequately covers purpose, usage, and return fields. It could mention pagination or ordering, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'ticker.' The description provides an example but does not add extra meaning beyond what the schema already provides (e.g., ticker format). 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 it gets institutional ownership data for a stock, specifying 'top holders and ownership changes from 13F filings.' This is a specific verb and resource, distinguishing it from sibling tools like 'veroq_insider' or 'veroq_congress.'
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 'WHEN TO USE' section provides clear context: 'To see which institutions own a stock and whether they're increasing or decreasing positions.' It does not explicitly state when not to use or name alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the operation returns trades with specific fields (member name, party, etc.) and costs 2 credits. However, it does not mention whether the operation is read-only, any authentication requirements, or rate limits. This is adequate but not fully rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: two sentences covering purpose, usage, return format, cost, and an example. It is well-structured with labeled sections, containing zero unnecessary 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?
For a simple tool with one optional parameter and no output schema, the description provides all necessary context: what it does, when to use it, what is returned, the cost, and a concrete example. There are no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (symbol) has 100% schema coverage with a clear description. The description reinforces optionality and provides an example. It does not add substantial new meaning beyond the schema, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get recent stock trades by members of U.S. Congress', using a specific verb and a distinct resource (congressional trades). This tool is unique among siblings (e.g., veroq_insider, veroq_ticker_news) as it focuses exclusively on political trading signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'WHEN TO USE: To track congressional trading activity — politically-informed trading signals' and advises filtering by ticker. While it does not provide negative guidance or list alternatives, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return structure ('Overall sentiment score, mention count, per-platform breakdown, trending topics, and top posts with URLs'), the data sources ('Reddit, Twitter/X, and other platforms'), and the cost ('30 credits'). However, it does not mention rate limits, error handling, or idempotency. For a simple read tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE) and the main sentence is front-loaded. It is not overly verbose, though the sections could be condensed into a single paragraph without losing information. Each part 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 parameter and no output schema, the description provides a reasonable amount of context: it explains the return data (sentiment score, breakdown, top posts) and cost. It lacks details on possible errors, data freshness, or pagination, but given the simplicity, it is 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?
The input schema has 100% description coverage for the only parameter 'symbol', with an example in the schema description. The tool description repeats the example but adds no new semantic information. Baseline is 3, and the description does not elevate 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?
The description clearly states the tool's function: 'Get social media sentiment for a stock or crypto ticker from Reddit, Twitter/X, and other platforms.' The verb 'get' combined with the specific resource 'social media sentiment' makes the purpose unambiguous. The tool is distinct from siblings like 'veroq_social_trending' which likely focuses on trending topics rather than sentiment.
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 includes a dedicated 'WHEN TO USE' section: 'To gauge retail investor sentiment and social buzz around a specific ticker.' This provides clear context for when the tool is appropriate, but it does not explicitly state when not to use it or mention alternatives (e.g., for earnings data). The guidance is strong but lacks negative cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the time window (24h), return format, cost (1 credit), and example. It does not mention idempotency or side effects, but as a read-only data retrieval tool, the description is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use, returns, cost, example) in only five sentences. Every sentence adds value with no redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers all necessary aspects: what it does, when to use, return structure, cost, time frame, and an example. It is fully complete for its complexity.
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 a single parameter 'limit' described as 'Max entities to return'. The description adds an example usage, which is marginal value beyond the schema. 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 explicitly states it gets trending entities (people, orgs, topics) with the most mentions in the last 24 hours. While it is clear, it does not distinguish from similarly named sibling tools like 'veroq_social_trending', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a 'WHEN TO USE' section that tells the agent to use it to discover what's dominating the news cycle and as a good starting point for research. 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 the description carries the full burden. It states the tool returns GDP values, growth rates, and historical comparison, and notes a cost of 1 credit. However, it does not disclose data freshness, update frequency, or any limitations. For a read-only tool, the behavioral disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose statement and structured sections (WHEN TO USE, RETURNS, COST, EXAMPLE). It is front-loaded and easy to scan, though the empty example adds no value. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers purpose, usage guidance, return values, and cost. It is sufficiently complete for the tool's simplicity, leaving no major gaps for an agent to understand what the tool does and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema coverage is 100% trivially, and the description does not need to add parameter meaning. The description correctly omits parameter details since none exist.
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 provides US GDP data from the World Bank with specific focus on gross domestic product and growth rates. The title 'veroq_world_gdp' is reinforced by the description, and it distinguishes itself from sibling tools like 'veroq_economy' or 'veroq_economy_indicator' by specifying US GDP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes a 'WHEN TO USE' section that advises using the tool for GDP data and economic growth analysis, and mentions its utility for macro context and long-term trend analysis. While it does not explicitly mention when not to use it or alternatives, the provided guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns a list with specific fields and costs 1 credit, but does not disclose potential side effects, authorization needs, or behaviors like pagination. For a simple list tool, this is adequate but not exceptional.
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 very concise, using labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE) to organize information. Every sentence adds value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers key aspects: purpose, usage context, return fields, and cost. It is sufficient for an agent to decide when and how to invoke it, though it could optionally mention if the list varies per user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter meaning, but it explains the return fields (slug, name, description, required inputs, credit cost), adding context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'lists available vertical agent packs' and specifies they are 'pre-built agent configurations for specific domains'. It distinguishes itself from sibling tool 'veroq_run_agent' by indicating it should be used before calling that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes a 'WHEN TO USE' section that tells the agent to use this tool to discover available packs before invoking 'veroq_run_agent'. This is clear guidance, though it does not mention any alternative or situation to avoid 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?
No annotations are provided, so description carries full burden. It explains returns (yields, spreads, inversion flags) and cost, but does not disclose read-only nature or any side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE). No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, description covers purpose, expected outputs, cost, and example. Minor omissions like data source or update frequency but not critical.
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?
Input schema has zero parameters (baseline 4). Description adds value by listing maturities and expected outputs, which is helpful.
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 'Treasury yield curve with inversion detection' and the WHEN TO USE section specifies checking US Treasury yield curve across maturities and detecting inversions. It is distinct from other tools like veroq_economy_indicator.
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 WHEN TO USE section explicitly states when to use the tool. However, it does not mention when not to use or alternatives, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses cost (3 credits), constraints (max depth 3, max 10 pages), and return values (page content, metadata, discovered links). This is transparent for a read-oriented tool, though rate limits or error handling are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, WHEN TO USE, RETURNS, COST, EXAMPLE, CONSTRAINTS). It is concise, front-loaded, and every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description mentions return values (page content, metadata, discovered links). It covers constraints, cost, and an example. For a relatively straightforward crawling tool, this is sufficient, though more detail on 'structured content' formatting could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds an example showing usage with 'url' and 'depth', but does not provide additional meaning beyond the existing schema descriptions for each parameter. No significant extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Crawl a URL and extract structured content with optional link following.' This uses a specific verb (crawl) and resource (URL), and distinguishes from siblings like veroq_extract by focusing on link following and multi-page crawling.
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 includes a dedicated 'WHEN TO USE' section: 'When you need to extract and analyze content from a specific webpage, or crawl a site's link structure.' This provides clear context, though it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses return format (list with type, date, description, URL) and cost (1 credit), offering good transparency for a read-only 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?
Description is concise with clear sections (overview, when to use, returns, cost, example), every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, description adequately explains return format; minor gap: 'recent' is vague but acceptable for a simple one-param tool. Sufficient given 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?
Input schema covers the only parameter 'ticker' with description; description adds an example but no extra semantics beyond schema, meeting baseline for 100% 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?
Description clearly specifies the tool retrieves recent SEC filings (10-K, 10-Q, 8-K) from EDGAR, distinguishing it from sibling tools like veroq_edgar_financials and veroq_edgar_insider.
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?
Explicit 'WHEN TO USE' section describes the use case (viewing a company's recent regulatory filings), providing clear context though no explicit when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states it returns an array and costs 1 credit, but does not disclose details like rate limits, authentication needs, or what happens if no data. Adequate but limited.
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?
Very concise, front-loaded with purpose, efficient use of lines: purpose, when to use, returns, cost, example. 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?
For a tool with no parameters and no output schema, the description covers the essential: returns array of tickers with scores. Could mention data format or structure, but overall sufficient for a simple overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. With 0 parameters, baseline is 4; description does not need to add parameter info.
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 provides all 78 tickers with signal scores as a heatmap-style overview. It distinguishes from sibling tools by focusing on a complete, unfiltered view.
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?
Includes a 'WHEN TO USE' section specifying it's for a complete view and building dashboards. Does not explicitly mention alternatives or when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses return format (array of tickers with scores and delta) and cost (1 credit). With no annotations, it carries the transparency burden well, but could further clarify data recency or cycle length.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with structured sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence is informative, and the example placeholder is harmless. 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 no output schema, the description fully covers purpose, usage, return format, and cost. It is complete for a query tool with no inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description correctly adds no parameter details. Baseline for zero parameters is 4, and the description meets that without redundancy.
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 identifies tickers with the biggest signal changes. It uses a specific verb ('identify') and resource ('tickers with biggest signal changes'). However, it does not explicitly differentiate from siblings like veroq_fast_signals or veroq_market_movers, leaving room for confusion.
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?
A dedicated 'WHEN TO USE' section explains its suitability for momentum or reversal detection. It provides clear context but lacks explicit when-not-to-use instructions or 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 provided, the description carries the burden. It mentions that results include links to SEC EDGAR and costs 2 credits, but does not disclose read-only nature, rate limits, or authentication requirements. The information is helpful 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 concise, well-structured with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE), and front-loaded with the most important information. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers expected return fields and cost. It is complete for typical use cases, though it omits error handling or edge cases. The information is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single parameter ticker). The description adds value by providing an example ('TSLA') and context that the ticker is for a stock. This exceeds the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent SEC filings for a stock, listing specific form types (10-K, 10-Q, 8-K) and providing an example. It effectively communicates the core function and distinguishes from sibling tools by specifying 'recent' and linking to EDGAR.
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 includes a 'WHEN TO USE' section explicitly stating contexts like regulatory filing history and due diligence. However, it does not mention when not to use or compare with similar sibling tools (e.g., veroq_edgar_filings), so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses cost (1 credit) and return format. As a read-only snapshot, it is sufficiently transparent, though it omits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 50 words, using a clean structure with bold headings for 'WHEN TO USE', 'RETURNS', 'COST', and 'EXAMPLE'. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description fully covers what the tool does, when to use it, what it returns, and its cost. No additional context appears necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description adds value by explicitly stating 'No parameters needed' and providing an example of an empty invocation, exceeding the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves today's top market movers including gainers, losers, and most active stocks. It uses specific verbs and lists components, but does not explicitly differentiate from similar sibling tools like 'veroq_fast_movers'.
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 includes a 'WHEN TO USE' section that specifies it's for a quick snapshot with no parameters needed. It provides clear context but does not mention when not to use it or offer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses behavioral traits such as cost (1 credit) and return structure (per-sector data including ticker count, brief count, average sentiment, top tickers). This goes beyond the input schema but could mention data freshness or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE) that front-load key information. Every sentence is useful and there is no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides sufficient context: purpose, use case, return fields, and cost. It is complete enough for an AI agent to select and invoke correctly, though it could clarify sentiment scale.
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 one parameter 'days' described as 'Lookback period in days (default 7)'. The description adds an example usage but no additional semantic detail beyond the schema, so baseline 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 verb 'Get', resource 'sector overview', and includes specific outputs like aggregate sentiment scores and brief counts. It distinguishes itself from sibling tools that focus on individual tickers or other macro data.
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 includes a 'WHEN TO USE' section that explicitly states the use case: macro view for sector rotation analysis. It provides clear context but does not explicitly list when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states it returns a composite disruption score, TSA counts, FAA ground stops, and border wait times, and mentions a cost of 1 credit. This is transparent for a read-only data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with sections (WHEN TO USE, RETURNS, COST, EXAMPLE), and front-loaded. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters or output schema, the description fully explains its purpose, usage, return values, and cost. It is complete for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds an example usage but no further parameter details needed. 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 clearly states it provides a 'Travel disruption score' combining TSA, FAA, and border data. It distinguishes from more specific siblings like veroq_travel_faa and veroq_travel_tsa by being an overview. However, it could be more explicit about what the disruption score means.
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 'WHEN TO USE' section explicitly states it's for a quick snapshot of US travel conditions. It does not provide when-not-to-use or alternatives, but the context is clear enough given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses cost (1 credit) and return fields (daily counts, YoY comparison, trend data), but does not detail data freshness, caching, or any limitations. For a read-only tool, this is adequate but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is highly concise (5 lines) with a clear structure: header, WHEN TO USE, RETURNS, COST, EXAMPLE. Every section serves a purpose with no redundant text.
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 parameters and no output schema, the description covers usage, returns, and cost. It could mention data frequency or source, but overall provides sufficient context for a simple data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. Per guidelines, 0 parameters yields a baseline of 4. The description adds no param info, which is acceptable given no params.
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 provides 'TSA daily passenger volumes — throughput data from US airport checkpoints.' This is a specific resource ('TSA passenger volumes') with a clear action (retrieve data). It distinguishes from siblings like 'veroq_travel_faa' which likely focuses on FAA data.
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 includes a 'WHEN TO USE' section specifying use cases: 'To track airport passenger volumes and compare to historical levels. Useful for travel industry analysis and consumer spending indicators.' However, it does not explicitly mention when not to use or alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states cost (3 credits), return fields, and optional verification. Missing rate limits or auth, but adequate for a read-only search 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?
Structured with clear headers (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence is purposeful and concise, with zero redundancy.
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?
No output schema, but description details return fields (titles, URLs, snippets, relevance scores, optional verification scores). Also includes cost and usage context. Complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by explaining 'verify=true' for trust scoring and providing an example with 'freshness' and 'verify'. Not all parameters elaborated, but sufficient.
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 clearly states 'Search the live web' with optional trust scoring. However, it does not differentiate from sibling 'veroq_search' which may be similar, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'WHEN TO USE' guidance: when intelligence briefs don't cover a topic and live web results are needed. Lacks when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses cost (1 credit) and return values (pageview counts, trend direction, percentile ranking). It does not explicitly state read-only behavior or rate limits, but the nature ('pageview-based interest signal') implies a safe retrieval operation. The description adds useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three short sentences plus structured sections (WHEN TO USE, RETURNS, COST, EXAMPLE). It is front-loaded with the core purpose and uses clear formatting. Every sentence adds value without redundancy.
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?
Despite lacking an output schema, the description specifies exactly what is returned (pageview counts, trend direction, percentile ranking), which is sufficient for an agent to understand the tool's output. It also mentions cost and data source (Wikipedia). For a simple single-parameter tool with 100% schema coverage, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a comprehensive description for the sole parameter 'entity' with examples ('NVIDIA, Elon Musk, Bitcoin'). The tool description only repeats the example and does not add semantic nuance beyond what the schema offers. Since schema coverage is 100%, baseline 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 returns a 'Wikipedia attention score' based on pageviews, specifying the resource (entity) and the signal type (interest). It distinguishes from sibling tools like veroq_alt_yields or veroq_alt_cot by focusing on public interest measurement, making the purpose unique.
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?
Includes an explicit 'WHEN TO USE' section: 'To gauge public interest... based on Wikipedia traffic. Spikes in attention often precede or accompany market moves.' This provides clear context and triggers. However, it does not mention when not to use it or name alternative tools, which would raise it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses cost (1 credit) and details of return value (body text, sources, entities, etc.). It implies readonly operation but does not explicitly state it's nondestructive.
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?
Description is well-structured with sections (WHEN TO USE, RETURNS, COST, EXAMPLE). It is concise, 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description fully explains return content (body, sources, entities, counter-argument, provenance). For a 2-parameter tool, this is complete and also includes cost information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with minimal descriptions. The description adds a concrete example for brief_id and clarifies include_full_text's effect, but overall adds limited value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get full details for a specific intelligence brief by its ID.' This is a specific verb and resource, and it distinguishes from siblings by noting it's used after search/feed to read full content.
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?
Explicitly says 'WHEN TO USE: After finding a brief via search/feed, use this to read the full body...' This provides clear context for when to use, though alternatives like veroq_search or veroq_feed are not named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost (1 credit), the return structure (array of briefs with headline, confidence, category, summary), and provides an example. It implicitly indicates this is a read operation with no side effects.
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 very concise at 6 lines, uses clear section headers ('WHEN TO USE', 'RETURNS', 'COST', 'EXAMPLE'), and every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description covers all essential aspects: purpose, usage guidance, return format, cost, and an example. It is complete for an agent to 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter 'name', which is fully described in the schema. The description adds an example usage { 'name': 'Elon Musk' }, which provides context but no additional semantic meaning beyond the schema. With 100% schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'intelligence briefs', and the scope 'specific entity'. It distinguishes itself from siblings by focusing on entity coverage across all briefs, which is unique among the many tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'WHEN TO USE' section that tells the agent exactly when to invoke this tool: when tracking coverage of a person, organization, or place. It does not provide explicit exclusions or alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full transparency burden. It lists return fields (Outlook, confidence, etc.) and cost (2 credits), but does not explicitly state if the operation is read-only or has side effects. Given the tool's nature, it's likely safe, but more explicit behavioral detail would improve score.
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 very concise, using headings (WHEN TO USE, RETURNS, COST, EXAMPLE) for clear structure. Every sentence adds value, and the main verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters and no output schema, the description covers all essential aspects: purpose, usage guidance, return format, cost, and an example. No critical information is missing.
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 baseline is 3. The description provides an example usage for the 'depth' parameter but adds no significant meaning beyond what the schema already states. The param descriptions are already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate a forward-looking forecast for a topic based on intelligence trends, momentum, and historical patterns.' It distinguishes itself from siblings like 'veroq_brief' and 'veroq_intelligence' by emphasizing predictive analysis.
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?
Includes a dedicated 'WHEN TO USE' section: 'When you need predictive analysis — likely outcomes, scenarios, and risk factors for a topic.' This provides clear context, but does not mention alternatives or when not to use, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description alone must disclose behavior. It mentions return fields (rate, change, etc.), cost, and example. However, it does not discuss auth requirements, rate limits, or error handling, which are relevant for a read 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?
Very concise with clear sections (purpose, when to use, returns, cost, example). Every sentence provides value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description fully covers purpose, usage, return structure, and cost. It is complete for the complexity level.
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?
Input schema is 100% covered with good description. The tool description adds context: 'No arguments returns all major pairs; pass a pair code for a single rate.' This reinforces schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get current foreign exchange rates' with clear verb and resource, and distinguishes from siblings by focusing on FX market data. It specifies scope: all major pairs vs single pair.
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?
Explicitly says 'WHEN TO USE: For currency exchange rates and FX market data.' Includes example and cost. While it doesn't explicitly exclude alternatives, the context is clear among financial data siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description details the return fields and cost. It does not explain how 'AI detection' works or define 'trending' timeframe, but is adequate for a simple read-only 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 well-structured with clear sections, but the empty EXAMPLE object adds no value and could be removed. Otherwise concise.
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 parameterless tool with no output schema, the description covers purpose, usage, return fields, and cost. It could clarify 'trending' definition, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no param info, which is appropriate; baseline 4 for zero 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 'Trending GitHub repos with AI detection' and specifies the resource and action. It distinguishes from sibling research tools (e.g., veroq_research_bills) by focusing on GitHub repos.
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 'WHEN TO USE' section provides clear context for tech trend analysis, but lacks explicit exclusions or alternative tool mentions. Sibling tools implicitly cover other domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes return types (headline and entity suggestions with details), cost (1 credit), and constraints, offering good behavioral insight for a read-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE, CONSTRAINTS). Every sentence adds value, and it is front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one parameter, no output schema), the description covers purpose, usage, return details, cost, and constraints comprehensively, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'query' described as 'Partial search query (minimum 2 characters).' The description adds an example but does not provide additional meaning beyond the schema, hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Get search autocomplete suggestions — matching headlines and entities for a partial query,' clearly stating the verb and resource. It distinguishes from sibling 'veroq_search' by advising to use it before running a search.
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?
Explicitly states when to use: 'To find the right search terms before running veroq_search.' Includes constraints (minimum 2 characters) and an example. Lacks explicit when-not-to-use scenarios, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description properly discloses that the tool returns a list of stories with specific fields (title, score, comment count, author, URL) and a credit cost of 1. It does not mention rate limits or authentication, but for a read-only data retrieval tool, the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-line headline followed by labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE). However, the EXAMPLE field contains an empty object, which is not a useful demonstration. Overall, it is well-structured and free of redundant 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 parameters and no output schema, the description adequately specifies the return fields and cost. It could optionally mention the number of stories returned or data freshness, but for a simple list tool, it is complete enough for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description's role shifts to explaining what the tool does and what it returns. It adds value by detailing the output fields and context, though the empty EXAMPLE is not helpful. Baseline 4 is appropriate for no 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 retrieves Hacker News top stories and what the tech community is discussing. It specifies the source (Hacker News) and provides a return list of fields, making the purpose unambiguous and distinct from sibling tools like veroq_trending or veroq_search.
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 includes a dedicated 'WHEN TO USE' section explaining the tool is for seeing trending Hacker News topics and tracking tech sentiment. It provides clear usage context but does not explicitly state when not to use it or mention alternative tools, which is acceptable given its simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It explains what each action returns (e.g., 'Create: alert ID and details'), mentions cost (3 credits), and enumerates alert types. It does not explicitly state non-destructive behavior, but the 'create' and 'list' actions imply safe operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (WHEN TO USE, RETURNS, COST, EXAMPLE, CONSTRAINTS). Every sentence adds necessary information, no fluff. It is front-loaded with the main purpose, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description covers all key aspects: actions, returns, cost, constraints, and an example. It is sufficient for an agent to invoke the tool correctly, though it could mention error handling or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for each parameter. The description adds value by providing the exact values for 'action' (create, list, triggered), a concrete example, and the list of 6 alert types. This helps the agent understand parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Create, list, or check triggered price/sentiment alerts.' It uses specific verbs and identifies the resource (alerts). Among many sibling tools, this one uniquely handles alert monitoring, making it clearly distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a 'WHEN TO USE' section: 'To set up automated monitoring.' It also lists the three actions and constraints (6 alert types). Although it lacks explicit when-not-to-use or alternatives, the context is clear enough for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details return data: consensus rating, mean/high/low targets, analyst count, and individual ratings. It also mentions the cost (2 credits). This adequately discloses behavior for a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence is necessary and information-dense, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, usage, return structure, cost, and an example. It could mention potential restrictions like ticker validity, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'ticker' parameter having a description. The description adds value through an example ('{ "ticker": "NVDA" }') and context about usage, going beyond the schema's basic definition.
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 'Get Wall Street analyst ratings and price targets for a stock,' providing a specific verb and resource. It distinguishes itself from siblings like 'veroq_earnings' and 'veroq_ticker_analysis' by focusing on analyst ratings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'WHEN TO USE: To see consensus analyst opinion and price target range for a stock,' offering clear context. It does not explicitly mention when not to use or alternatives, but the given guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description accurately describes the tool as returning current prices and inventory levels. It mentions a cost of 1 credit, which is helpful. The tool is read-only, so no destructive behavior to disclose. The description is transparent enough for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE) to organize information. Every sentence adds value with no redundancy. Ideal length and structure.
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 has no parameters, no output schema, and is a straightforward data retrieval, the description covers the essential aspects: what data is returned and its purpose. Could optionally mention update frequency or data sources, but it's sufficient for an overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so no parameter description is needed. The schema coverage is 100%. Baseline score of 4 is appropriate as the description adds no parameter info but none is required.
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 provides oil prices, petroleum inventory, and natural gas data with specific examples (WTI/Brent). It distinguishes itself from sibling tools by focusing on energy market snapshot, unlike broader commodity or crypto tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE' section explicitly states the use case: 'for a snapshot of the energy market'. It doesn't mention when not to use, but the context of many sibling tools makes the differentiation clear. No explicit alternatives are listed, which is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description discloses it's a read operation, returns score/direction/factors, and costs 1 credit. However, it does not mention error handling or edge cases like invalid tickers.
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 very concise: 4 sentences covering purpose, usage, returns, cost, and example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 1 parameter and no output schema, the description covers purpose, usage, returns, and cost. It could optionally detail output structure but is 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?
Schema coverage is 100% and the parameter description is already clear. The description only uses the ticker in an example, adding no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a pre-computed signal for one ticker, a fast lookup. It distinguishes itself from the sibling tool veroq_ticker_score by highlighting speed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The WHEN TO USE section explicitly tells when to use this tool (for quick signal) and names the alternative (veroq_ticker_score). Offers clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses returns (array with fields), cost (1 credit), and example. Does not mention pagination or rate limits, but is sufficient for a read-only feed.
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?
Structured with targeted sections: header, WHEN TO USE, RETURNS, COST, EXAMPLE. Every sentence is informative and 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?
Specifies return type and fields, cost, and usage example. No output schema, but description covers essentials. Could mention pagination or error conditions, but adequate for a simple feed.
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. Description includes an example using 'category' and 'limit', which adds practical usage context but does not significantly surpass 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?
Explicitly states 'Get the latest verified intelligence briefs in reverse-chronological order' and distinguishes from sibling by mentioning browsing without a query vs. searching with a topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear WHEN TO USE section: 'For browsing recent news without a specific search query. Use veroq_search when you have a topic in mind.' This directly guides tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It discloses cost (5 credits), return types (impact scores, tickers, etc.), and example. Minor omission: no mention of data freshness or if results are cached, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a brief sentence, followed by clear labeled sections (when to use, returns, cost, example). Every sentence earns its place with 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 and simple input, the description covers input, output, use case, and cost. Could specify output format more precisely, but for a single-param tool, it's 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?
Schema has 100% coverage for the single parameter (topic) with a good description. Description adds an example and restates purpose, but does not significantly enhance beyond schema. Baseline 3 applies per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs cross-category impact analysis, with a verb ('analyze') and resource ('how a topic affects multiple sectors and asset classes'). It distinguishes itself from siblings like veroq_events or veroq_compare by focusing on second-order effects across sectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly includes a 'WHEN TO USE' section with a concrete example (Fed rate decision impacting multiple asset classes), giving clear guidance on appropriate use cases. No explicit exclusion, but the positive context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It states returns (holdings summary, ranked briefs), credits cost, and example. Discloses read-only behavior and key output structure adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line action, followed by brief sections (WHEN, RETURNS, COST, EXAMPLE). Every sentence adds meaningful information, no fluff. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though no output schema, description explains return structure and usage clearly. Covers purpose, when-to-use, example, cost. Could add detail on relevance scoring, but current description is sufficient for an agent to understand tool behavior.
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 baseline 3. Description adds value by explaining 'ticker/weight pairs' yield impact-ranked coverage, and providing an example that clarifies parameter semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves intelligence briefs ranked by relevance to portfolio holdings, using strong verb 'Get' and specific resource. Differentiates from sibling tools like veroq_feed by specifying portfolio context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE section: 'When monitoring news for a specific portfolio.' Provides clear usage context. Lacks explicit when-not-to-use or alternative tools, but guidance is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure responsibility. It details the return format (list of recent FDA actions with drug name, company, action type, date, details) and mentions a cost of 1 credit. This adds value beyond the empty schema, though it could note that the tool is read-only or has no side effects.
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 very concise, using labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE) for quick scanning. Every sentence serves a purpose, and there is no wasted text. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters and no output schema, the description covers all essential dimensions: purpose, usage, return data, and cost. It lacks information about the time range of 'recent' actions or how many results are returned, but overall it is sufficiently complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description does not need to elaborate on parameters, as there are none. A baseline of 4 is appropriate for zero-parameter tools where the schema is fully described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: tracking FDA drug approvals, rejections, and recalls. The verb 'track' is implied, and the resource is specific (FDA regulatory actions). It distinguishes itself from sibling research tools like veroq_research_bills or veroq_research_regulations by focusing on FDA approvals and recalls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'To track FDA drug approvals, rejections, and recalls. Important for biotech/pharma stock analysis.' This provides clear context and intended audience. It does not explicitly mention when not to use it, but given the zero-parameter simplicity, that is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses cost (20 credits), return fields (symbols, name, mention count, sentiment, 1-hour change), and that no parameters are needed. It does not mention rate limits or side effects, but for a read-only trending tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a clear front-loaded purpose, followed by structured sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. Description covers purpose, usage, returns, and cost. It could mention update frequency or data freshness, but it is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%, so the description doesn't need to add parameter details. It does add value by explaining the return structure, which compensates for the absence of 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 it retrieves tickers and topics trending on social media platforms, with a specific verb and resource. It is distinct from siblings like veroq_trending (general trending) and veroq_social_sentiment (sentiment analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes a 'WHEN TO USE' section, stating it's for discovering what retail investors are buzzing about, and notes no parameters needed. However, it does not mention when not to use or provide alternatives, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'Active ground stops, ground delay programs, airport closures, and general delay information' and mentions a cost of 1 credit. This is sufficiently transparent for a read-only data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a one-line header, then structured sections for WHEN TO USE, RETURNS, COST, and EXAMPLE. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers its purpose and return information. It could mention the return format (e.g., list of delays) but is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema coverage is 100% (empty object). Per guidelines, 0 parameters yields a baseline of 4. The description includes an example call with an empty object, which 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 specifies that the tool provides live FAA data on ground stops and airport delays. It uses specific verbs ('check', 'live data') and resource ('FAA'), and distinguishes itself from travel-related siblings like veroq_travel_tsa and veroq_travel_overview by focusing on FAA-specific disruptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a 'WHEN TO USE' section: 'To check for current airport delays, ground stops, or airspace disruptions in the US.' This gives clear context, but it does not mention when not to use it or direct to alternative tools for non-US travel data.
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?
Description discloses returns (latest figures, historical comparison, metrics) and cost (1 credit). Since no annotations are provided, it carries the full burden; it is clear about the read-only nature implicitly. No mention of auth or rate limits, but adequate for a simple data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured with sections: main line, WHEN TO USE, RETURNS, COST, EXAMPLE. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description covers purpose, usage, returns, and cost. It mentions historical comparison and labor market metrics, though could elaborate on update frequency or specific indicators. Still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters (100% coverage), so baseline is 4. Description adds meaning by specifying what data is returned, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides BLS employment data (nonfarm payrolls, unemployment rate, labor market indicators) for the US. It distinguishes itself from siblings by specifying the source and focus on US employment, which is different from other economic tools like veroq_economy.
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?
Explicit 'WHEN TO USE' section specifies US employment data from BLS and its use for market analysis and Fed policy expectations. It does not mention when not to use or provide alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses returns (aggregated briefs, entities, timeline, related topics) and cost (3 credits). Lacks detail on rate limits or performance, but sufficient for a read-only research 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?
Well-structured with labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Concise at 3 sentences plus example, 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?
For a single-parameter tool with no output schema, description fully covers purpose, usage, return content, cost, and example. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'topic' with 100% schema coverage. Description adds example usage but doesn't significantly extend schema meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Full background research on a topic' with specific outputs (briefs, entities, timeline). Distinguishes from sibling veroq_ask by noting it returns raw context rather than a synthesized answer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE section: 'When you need comprehensive background on a topic before answering a complex question.' Also contrasts with veroq_ask, providing clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It describes return format (array with fields) and cost (2 credits). Does not mention rate limits or auth, but sufficient for a read-based tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with clear sections (purpose, when to use, returns, cost, example). Every sentence adds value.
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 low complexity (one optional param, no output schema), the description fully covers purpose, usage, return format, and cost. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with description for severity. Tool description additionally provides an example usage, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds contradictions across intelligence briefs, using a specific verb 'find' and resource. It distinguishes from siblings focusing on financial data or news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'To identify conflicting narratives... Useful for risk assessment and due diligence.' It does not mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses return data (price, volume, market cap, period change %), cost (2 credits), and constraints (max 365 days). Could mention authentication needs, but overall strong for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-organized with labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE, CONSTRAINTS). Every sentence adds value; no fluff. Perfect length and structure.
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 output schema, description adequately explains return values. It covers purpose, usage, returns, cost, example, and constraints. With only two simple parameters, this is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds an example and restates the 365-day constraint, but the schema already includes default and max for days. Marginal added value beyond 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 clearly states 'Get historical price chart data for a crypto token' with specific verb and resource. Distinguishes from sibling 'veroq_crypto' which is for current snapshot, so agent knows exactly which tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'WHEN TO USE' section: for crypto price history and charting, and directs to 'veroq_crypto' for current snapshot. This gives clear context and alternative, meeting the highest standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It discloses cost (2 credits), maximum observations (100), and return structure (series info, latest value, historical array). It does not explicitly state read-only behavior, but it's implied; minor gap prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE, CONSTRAINTS), front-loading key information with zero waste. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return values in detail ('Series info (ID, frequency, units), latest value, and historical observations array') and includes constraints, which compensates for the lack of an output schema. The tool is simple, and the description covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (100% coverage). The description's example adds no new semantic info beyond the schema, resulting in baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a specific FRED economic indicator with historical observations, using a specific verb ('Get') and resource. It distinguishes from the sibling 'veroeq_economy' which provides a summary without arguments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'WHEN TO USE' section detailing that it is for detailed history of one indicator, and directs to 'veroeq_economy' for a summary. Also includes cost and constraints, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes cost (2 credits) and output format (transaction list with fields, summary stats). No annotations provided, so description carries burden well, though no mention of authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence adds value; no fluff. Front-loaded with key purpose.
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?
Complete for a single-parameter read tool: covers purpose, usage guidance, cost, and output structure. No missing critical information.
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% for the only parameter 'ticker'. Description adds an example JSON ('{"ticker": "AAPL"}'), adding clarity beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'get', resource 'insider trading activity', and specific source 'SEC Form 4 filings'. Distinguishes from siblings like 'veroq_edgar_insider' by focusing on executive/director activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'WHEN TO USE' section: to check insider buying/selling. Lacks explicit alternatives or when-not-to-use, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the output format, cost (3 credits), and example usage. It does not mention side effects or permissions, but as a research tool, it is likely read-only and non-destructive. Could add details on auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with six sentences covering purpose, usage guidance, return values, cost, and an example. No extraneous information.
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?
Despite no output schema, the description details the return values (summary, key findings, entity map, etc.) and includes cost. For a multi-source research tool, this provides sufficient context for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the description adds little beyond the example. The parameter descriptions in the schema are sufficient but the description does not further clarify semantics or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs deep multi-source research and produces a structured report, differentiating it from sibling tools like veroq_search. The verb 'run' and resource 'research' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' section explains it is for thorough investigation and directs to use veroq_search for quick lookups, providing clear guidance on 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 bears full burden. It explains returns and cost but does not explicitly state read-only nature, idempotency, or potential side effects. The provided return structure (execution steps, status) adds some behavioral context but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE), making it easy to scan. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description adequately covers when to use, return values, cost, and a concrete example. It sufficiently differentiates from the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters ('slug' and 'inputs') have schema descriptions (100% coverage). The description adds value with concrete examples of slugs (e.g., 'due-diligence') and inputs (e.g., { ticker: 'AAPL' }), helping the agent understand variability beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and the resource 'VEROQ AI agent by its slug', and distinguishes it from siblings by emphasizing it handles complex multi-step workflows, unlike the many single-purpose tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE' section explicitly recommends this tool for complex multi-step analysis tasks like portfolio reviews, due diligence, or market scans, and implies that individual tool calls are more appropriate for simpler tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses cost (2 credits), return structure (signal summary and indicator values), and provides an example. However, it does not explicitly state that the tool is read-only or requires authentication, but the context implies no mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections for when to use, returns, cost, and example. Every sentence adds value, and there is no redundant or missing information.
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?
Despite no output schema, the description details the return values (signal summary, indicator values). It covers inputs, outputs, usage context, and cost, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds an example and lists 'symbol' and 'range' but does not provide additional semantic meaning beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves major technical indicators (RSI, MACD, Bollinger Bands, moving averages) and an overall signal summary. It distinguishes itself from sibling 'veroq_candles' by specifying it returns pre-computed analysis rather than raw price data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' section guides the agent to use this tool for pre-computed technical analysis and directs to 'veroq_candles' for raw data. This provides clear context and alternatives, helping avoid incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses return format (array of briefs with headline, confidence, category, summary, total brief count) and cost (1 credit). Could mention error handling but sufficient for a read 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?
Description is concise, front-loaded with purpose and usage, uses clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence adds value.
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?
Even without output schema, description fully explains return structure, cost, and provides an example. Simple tool and context signals indicate good completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides 100% coverage with descriptions for both parameters (symbol and limit). Description adds no extra semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get recent news headlines and briefs for a specific stock or crypto ticker', which is a specific verb+resource. It also distinguishes from siblings like veroq_search and veroq_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE section states 'For ticker-specific news' and provides alternatives: 'Use veroq_search for topic-based search, or veroq_feed for general news.' This is clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses cost (2 credits) and return structure (array with version, timestamp, summary, etc.), implying a read-only operation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five compact sentences front-loading purpose, then usage, returns, cost, and example. No redundancy, every sentence serves a purpose.
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 one parameter and no output schema, the description sufficiently explains what the tool does, when to use it, what it returns, and the cost. Example fills remaining context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description. The description adds an example format ('PR-2026-0305-001') and ties it to the prerequisite, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a story evolution timeline for a living brief, including versioned updates, confidence changes, and new sources. It distinguishes itself from siblings like veroq_brief and veroq_diff by focusing on temporal evolution.
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?
Explicit 'WHEN TO USE' and requirement for a brief ID from search/feed provide clear context. It does not mention when not to use or alternatives, but the specific use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description details return structure (structured data, LLM summary, trade signal, confidence, follow-ups), cost (1-5 credits), caching (60s/30s), and fast flag behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses clear headers (WHEN TO USE, RETURNS, COST, EXAMPLES, CONSTRAINTS) and front-loads the importance. It is informative but slightly verbose; however, each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description comprehensively covers returns, cost, caching, constraints, and gives concrete examples. For a tool with 41 intents and many sibling tools, this provides sufficient context for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the 'fast' parameter's effect (skip LLM summary, save ~2 seconds) and the 'question' parameter's scope. This enhances understanding beyond the schema 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 it is the default tool for natural language questions about finance, markets, and economics, automatically detecting 41 intents. It distinguishes itself from numerous sibling tools by being the first resort and covering a wide range of queries.
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?
Explicitly instructs 'Use this FIRST before reaching for specialized tools' and provides WHEN TO USE context. However, it does not explicitly state when not to use it or which sibling tools to use for specific intents, though examples and constraints offer implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It mentions 'COST: 1 credit' and describes the return type, but does not disclose any side effects, rate limits, or data freshness. The description is adequate for a read-only data retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with distinct sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence serves a purpose, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return type in sufficient detail for a simple list tool. It covers cost and purpose. However, it lacks information on pagination, limits, or error conditions, which could be relevant for heavy usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the single parameter with a clear description and example values. The description adds an example invocation ('{ "ticker": "TSLA" }'), which adds practical value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Form 4 insider trades for a company from SEC EDGAR', which is a specific verb-resource combination. It distinguishes itself from its sibling 'veroeq_insider' by noting it uses a different data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE' section explicitly tells the agent to use this tool for insider buying/selling activity and notes it complements veroeq_insider, providing clear context for when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns an array with direction, score, and factors, costs 1 credit, and is pre-computed/refreshed. It does not mention any side effects or limitations, but for a read-only data operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single line for purpose followed by short labeled sections (WHEN, RETURNS, COST, EXAMPLE). Every sentence adds value with no redundancy, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers core aspects: purpose, usage scenario, return structure, and cost. It could benefit from specifying the exact fields in the returned array or the refresh frequency, but it is still sufficient for an agent to decide to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage. Per guidelines, the baseline for 0 params is 4. The description does not need to add parameter details, and it provides an empty example request ({}), which is consistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it provides pre-computed buy/sell signals across 78 tickers, refreshed every cycle. This clearly defines the verb (provide), resource (signals), and scope (78 tickers, refreshed), distinguishing it from siblings like veroq_ticker_analysis (individual analysis) and veroq_screener (customizable).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE' section directly advises using it for a quick overview of all active signals without individual analyses, and for scanning opportunities. This explicitly provides context and differentiates from alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details return fields, cost, and search type. Implies read-only search; minor gap: no explicit statement on side effects or safety, but sufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Each sentence serves a purpose; no redundancy. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explicitly lists return fields (headline, confidence score, etc.). Covers cost and basic usage. Missing pagination or default limit info, but schema covers limit default.
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 baseline 3. Description adds value with a concrete example showing query, category, and limit usage, enhancing understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Search verified intelligence briefs by keyword or topic', clearly stating verb and resource. It distinguishes from sibling 'veroq_ask' by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' section gives clear context and alternatives, including 'Use veroq_ask for natural-language questions instead'. Also mentions cost and returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses cost (2 credits) and outlines return fields, which is adequate for a read operation. Could mention if data is cached or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (purpose, when to use, returns, cost, example). Every sentence adds value; no waste.
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?
No output schema, but description lists return fields comprehensively (outlook, sentiment, factors, etc.). Could be improved by specifying response format or data types, but sufficient for intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with schema coverage 100%. Description adds an example and explains the symbol format, which provides extra clarity beyond the schema's 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 'Get a comprehensive analysis for a ticker' with specific components, and distinguishes from sibling 'veroq_full' by contrasting raw data vs interpreted analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'WHEN TO USE' clause, including an alternative tool (veroq_full) and context for when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description adds return format ('Array of candles with date, open, high, low, close, volume. Latest candle highlighted') and cost ('2 credits'). It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with distinct sections for purpose, usage, returns, cost, and example. Every sentence is relevant, no fluff. Front-loaded with the core action.
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?
All parameters are documented in the schema, and the description outlines the return data and cost. Given the tool's simplicity and the rich sibling list, the description provides enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (100%), but the description provides an example usage with typical values ('symbol': 'AAPL', 'interval': '1d', 'range': '3mo'), adding practical value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get OHLCV candlestick data for a stock ticker', specifying the verb, resource, and scope. It distinguishes from siblings like veroq_technicals, which offers pre-computed indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'WHEN TO USE' section and an alternative sibling ('Use veroq_technicals for pre-computed indicators'), providing clear guidance on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explains the two operating modes, returns structure, cost, and includes an example. However, it does not disclose idempotency, error handling, or rate limits. For a read-only data retrieval tool, this is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence adds essential information without redundancy, achieving maximum conciseness.
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?
Despite no output schema, the description fully explains the two return modes. For a simple tool with two optional parameters, this covers all necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds value by clarifying that omitting 'indicator' triggers summary mode and provides an example URL-like usage. This exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves macroeconomic indicators from FRED, with distinct summary and detail modes. It explicitly names a sibling tool (veroq_economy_indicator) for single-indicator queries, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains a dedicated 'WHEN TO USE' section specifying typical indicators (GDP, CPI, unemployment) and directs the agent to an alternative tool for single indicator history. This provides explicit guidance on context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool fetches data in parallel from 9 sources, costs 2 credits, and returns multiple data categories. Does not mention rate limits or error conditions, but adequate for a read-only data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with clear sections: purpose, when to use, returns, cost, and example. Every sentence adds value; 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?
For a single-parameter tool with no output schema, the description fully explains what it returns (price, fundamentals, technicals, sentiment, news), how it works (parallel fetch), and cost. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides adequate description for 'ticker' parameter. The description adds an example usage, which clarifies expected format beyond the schema. Since schema coverage is 100%, baseline is 3, but the example raises it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves the full profile for a ticker, enumerating data categories. Distinguishes itself from the sibling tool 'verog_ticker_analysis' by noting that tool provides interpreted analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit WHEN TO USE section with clear condition ('complete data dump on a single ticker') and points to alternative for interpreted analysis. Also mentions parallel retrieval of 9 sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, the description carries the transparency burden. It discloses async generation needing retrieval via 'veroq_get_report', costs, and returns. Lacks details on potential failures or rate limits but is largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (WHEN TO USE, RETURNS, COST, EXAMPLE) and every sentence adds value. 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 output schema, the description adequately explains return values and the async flow. It differentiates among many sibling tools and provides all necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description adds value by clarifying the default 'quick' tier, cost per tier, and providing an example of 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 verb 'Generate' and the specific resource 'AI-powered research report for a ticker'. It also notes the async nature and distinguishes from the inline analysis sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a 'WHEN TO USE' section, contrasting with 'veroq_ticker_analysis' for instant inline analysis. Also mentions cost and tier choices to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost (1 credit) and describes the return structure (title, ticker, tier, date, markdown). While it doesn't mention error handling or rate limits, these are less critical for a simple retrieval tool. The transparency is good but could be slightly more 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 highly concise: four short lines covering purpose, usage, returns, cost, and example. Every sentence earns its place, and the use of labeled sections (WHEN TO USE, RETURNS, COST, EXAMPLE) makes it easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter retrieval tool with no output schema, the description is complete. It tells the agent what the tool does, when to use it, what it returns, its cost, and provides an example. No gaps remain for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for report_id. The description adds value by providing an example value ('rpt_abc123') and the context that the ID comes from generation. This goes beyond the schema's bare 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 'Retrieve a previously generated report by its ID.' The verb 'retrieve' with the specific resource 'report by ID' makes the action unambiguous. It distinguishes itself from sibling tool veroq_generate_report by implying this is for fetching after generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage context: 'WHEN TO USE: After calling veroq_generate_report, use this to fetch the completed report content.' This clearly tells the agent when to invoke this tool versus alternatives, and it gives an example input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (price, change, change percent) and cost (1 credit), which is helpful. However, it does not mention potential rate limits, data freshness, or any side effects; still, the provided details are sufficient for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four short sentences, with the purpose front-loaded. Every sentence adds value: purpose, usage, return format, cost, and example. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is nearly complete. It lists the indices and return fields. A slight improvement would be to mention that the data is a snapshot, but this is not critical. It adequately prepares the agent for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the input schema has 100% coverage. The description explicitly states 'No parameters needed', which reinforces the schema and requires no further explanation.
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 current values for major market indices (S&P 500, Nasdaq, Dow Jones, VIX). It uses a specific verb 'Get' and lists the indices, making the purpose unambiguous and distinct from sibling tools like 'veroq_crypto' or 'veroq_commodities'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly includes 'WHEN TO USE: For a quick check on how the overall market is doing. No parameters needed.' This provides clear context and tells the agent exactly when to invoke this tool versus alternatives, with no parameters to configure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds 'COST: 5 credits' and lists return fields. For a screening tool, this is sufficient; no side effects or authorization needs are implied, and it does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections (WHEN TO USE, RETURNS, COST, EXAMPLE), concise, and front-loaded. Every sentence adds value.
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?
No output schema, but description lists return fields. Given the 12 optional parameters and complexity, the description covers purpose, usage, cost, and example, making it sufficiently complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The example usage (`{ 'sector': 'Technology', 'rsi_below': 30, ... }`) adds concrete context that helps an agent understand parameter combinations beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'screen' and resource 'stocks or crypto', and distinguishes from sibling 'veroq_screener_presets' by directing users to that tool for pre-built strategies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a dedicated 'WHEN TO USE' section that gives concrete examples (e.g., oversold tech stocks) and explicitly mentions the alternative tool for pre-built strategies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It discloses the two output modes (list vs. run), cost (1 credit), and returned fields. Could mention idempotency or safety (read-only), but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with sections for purpose, when-to-use, returns, cost, and example. Every sentence adds value, front-loading the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description fully explains both modes, their outputs, cost, and provides an example. No gaps remain.
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 a clear parameter description. The description adds value beyond schema by mentioning the exact number of presets (12), cost, and output structure for both modes, helping the agent understand the parameter's effect.
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 dual function of the tool: listing presets or running one by ID. It uses specific verb+resource (List/run pre-built screening strategies) and distinguishes from manual screening tools like veroq_screener.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit WHEN TO USE guidance, explains when to omit vs. include preset_id, and gives an example. This helps the agent decide between listing and running, and when to use this tool over other screening tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description lists return fields and notes the tool is free (0 credits). It does not mention side effects or rate limits, but for a simple read-only price check, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences plus structured sections for WHEN, RETURNS, COST, EXAMPLE. No wasted words, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers all needed aspects: purpose, usage guidance, return fields, cost, and an example. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a good description for 'symbol'. The description adds an example and clarifies it works for stocks and crypto, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get', the resource 'live market price', and specifies it works for both stock and crypto tickers. It distinguishes from sibling 'veroq_full' which provides full analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('quick price check'), notes it's free, and directs to 'veroq_full' for full analysis, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses cost (2 credits) and return structure (composite score, signal, component breakdown). It does not mention side effects, but as a read operation, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully covers purpose, usage context, return values, cost, and an example. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'symbol', which is well described. The description adds an example request `{ "symbol": "NVDA" }`, providing extra clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets a composite trading signal score for a ticker based on sentiment, momentum, coverage volume, and event proximity. It distinguishes from sibling tool veroq_ticker_analysis, which provides deeper context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'WHEN TO USE' guidance: for a quick bull/bear signal on a ticker, and directs to use veroq_ticker_analysis for deeper context. Clear when-to-use vs alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses 'COST: 2 credits' which is a behavioral trait. It also clearly indicates read-only query behavior, but could mention data freshness or rate limits. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with separate sections (WHEN TO USE, RETURNS, COST, EXAMPLE). Every sentence is informative and earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers all necessary aspects: purpose, usage, return data, cost, and an example. It also references a sibling tool, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context: explains that omitting the parameter gives an overview, includes an example ('aave'), and details return fields for protocol (TVL, 1d/7d/30d changes, category, chains) which are not in the schema. This greatly enhances parameter understanding.
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 'Get DeFi data' and explains two distinct behaviors: no argument returns overview, passing a slug returns protocol details. It explicitly distinguishes from sibling 'veroq_defi_protocol', making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE' section explicitly states to use this for DeFi TVL data across protocols and chains, and recommends 'veroq_defi_protocol' for a single protocol deep dive, providing clear guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes exactly what is returned for each mode (market cap, BTC dominance, volume for overview; price, change, supply, ATH for token). No annotations to contradict; fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (description, when to use, returns, cost, example). Every sentence is informative and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is fully complete: covers usage, return fields, cost, and sibling alternative.
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%, but description adds value by explaining omission for overview and providing a concrete example with 'ETH'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get cryptocurrency data' with two distinct modes: market overview (no args) and detailed token data (with symbol). Distinguishes itself from sibling veroq_crypto_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE section with scenarios and alternative tool mention. Includes cost and example for clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description discloses key behavioral traits: it returns TVL, 1d/7d/30d change percentages, category, and deployed chains. Also mentions cost of 2 credits and provides an example. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose, usage guidelines, return fields, cost, and example. Every sentence serves a clear purpose with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with single parameter and no output schema, description covers all necessary aspects: what it does, when to use, what it returns, cost, and example. Sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of 'protocol' parameter. Description adds value by including an example usage ('{"protocol": "uniswap"}') which reinforces correct invocation.
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 the verb 'Get' and resource 'detailed DeFi protocol data including TVL, chain deployment, and performance changes'. It clearly distinguishes from sibling 'veroq_defi' which provides a full market overview without arguments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'WHEN TO USE' section: 'For a deep dive into a single DeFi protocol. Use veroq_defi (no args) for the full DeFi market overview.' This gives clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read (readOnlyHint) and external fetching (openWorldHint). Description adds cost (3 credits), cache durations, fallback to live web, and claim length constraints, providing full behavioral disclosure without contradiction.
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?
Well-structured with clear sections (WHEN TO USE, RETURNS, COST, EXAMPLES, CONSTRAINTS). Only necessary sentences, no fluff, and front-loaded with key purpose.
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?
Complete description for a tool with no output schema: covers when to use, input constraints, return structure (verdict, confidence, evidence_chain, receipt), cost, caching, and examples. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage but description adds value: specifies claim length (10-1000 chars), encourages specificity, and explains 'context' as category hint. This goes beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool is for fact-checking claims with evidence. It specifies verb 'verify', resource 'claim', and features like evidence chain and confidence breakdown, distinguishing it from numerous sibling data/analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' section advises using after any agent makes factual claims, especially about financial data, and proactively for assumptions. Provides clear context and alternatives (other veroq tools) are implicitly distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description compensates fully: it states that the tool returns a list of bills with specific fields, and mentions 'COST: 1 credit.' There is no destructive behavior implied. The description is transparent about output and cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines of purpose, a short 'WHEN TO USE' sentence, one line for returns, one for cost, and an example. Every sentence is necessary and informative. No extraneous text.
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 that the tool has no parameters and no output schema, the description provides all needed context: purpose, usage scenario, return format, cost, and a sample invocation (empty object). It is fully sufficient for an agent to decide when to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema description coverage is 100% trivially. The description adds value by specifying the return data ('title, sponsor, status, introduced date, and summary'), which helps the agent understand what will be received. Since no parameters exist, the description's clarification of output is essential.
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 'Recent Congressional bills — legislation that may affect markets.' It identifies the specific resource (Congressional bills) and purpose (market-impact analysis). The sibling tools like veroq_research_fda and veroq_research_github are distinct domains, so differentiation is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has an explicit 'WHEN TO USE' section: 'To track new legislation in the US Congress that could impact industries or markets. Good for policy risk analysis.' This directly tells the agent the appropriate context. No need for when-not because the use case is narrow.
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:

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

Score Badge

Copy to your README.md:

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

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