Skip to main content
Glama

Revexa: B2B buying signals

This week's B2B funding rounds

recent_b2b_funding_rounds
Read-onlyIdempotent

Lists B2B companies that announced funding rounds this week, as reported by European and US tech news, with amount, round, country, what the company does and the source article. Collected weekly from open news feeds (tech.eu, EU-Startups, TechCrunch and others).

Input Schema

NameRequiredDescriptionDefault
limitNo
regionNoany

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful context beyond them: the provenance (tech.eu, EU-Startups, TechCrunch) and the weekly collection cadence, which tells the agent how stale results may be. Rate limits and result ordering are unaddressed.

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?

Front-loaded with the core purpose in the first clause, followed by the field list and data-source note. Two sentences with little waste; the provenance sentence runs slightly long but still carries relevant 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?

With no output schema, the description usefully enumerates the returned fields, and it discloses data provenance and cadence for a low-complexity two-parameter tool. It falls short on the meaning of the parameters and the precise boundary of 'this week', but the core picture is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the two parameters but does not. 'limit' is never mentioned, and 'region' is only obliquely implied by the phrase 'European and US tech news' rather than as a filterable enum (europe/us/any).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Lists') and resource ('B2B companies that announced funding rounds this week'), and enumerates the returned fields (amount, round, country, description, source article). The domain is unmistakably distinct from the sibling tools, which concern hiring and a person named Leo.

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 note that data is 'collected weekly from open news feeds' implicitly signals a freshness/recency constraint an agent should account for. However, it never states when to prefer this tool over alternatives nor any exclusions, so usage must be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources