Skip to main content
Glama

AkkruData

by ai.akkrudata
OverviewDiscussionsAdmin

Get a subset of metrics

get_metrics_subset
Read-onlyIdempotent

Fetch a subset of computed metrics for one metric_group_id (same 148 credits as get_metrics_bundle; use it to keep the response small when you already know the names). metric_names must be ids from the metric catalog (e.g. gross_margin — not /data/facts labels like Revenue). Partial success: valid names are returned; unknown or unavailable names are listed in _metric_name_errors with _supported_metric_names (comma-separated, 9 ids per line) when anything failed to match. Same optional flags as get_metrics_bundle, plus light_weight_mode (bool, default false; strip per-metric audit fields to reduce payload size). POST /api/v1/metric/items; FINANCIAL_API_DOCUMENTATION.md. Requires the Starter plan or higher; formula_override requires Pro+.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_of_dateNoAs-of date "YYYY-MM-DD"; excludes filings filed after this date. Defaults to no cutoff.
metric_namesYesMetric ids from the catalog to return, e.g. ["gross_margin", "pe_ratio"] (1–100). Use list_screener_filters to see valid ids.
current_priceNoCurrent share price in USD for realtime price-sensitive ratios (> 0, ≤ 10,000,000, ≤ 4 decimals). Omit to get a hint instead.
current_fx_rateNoFallback FX rate, used only when an up-to-date conversion rate is briefly unavailable on foreign-issuer filings (> 0, ≤ 1,000,000, ≤ 6 decimals).
metric_group_idYesSnapshot id from list_metric_snapshots identifying one filing-period's computed metrics.
formula_overrideNoOptional per-metric formula overrides, keyed by metric id, e.g. {"interest_coverage": {"concepts": ["OperatingIncomeLoss", "InterestExpense"], "operators": ["/"]}}. Each entry lists XBRL concepts and the operators combining them. Requires the Pro plan or higher.
light_weight_modeNoWhen true, return a leaner payload (drops the most verbose nested fields). Charged the same. Saves context when you already know exactly what you need.
accept_suggested_formulaNoWhen true, accept the server's suggested formula for metrics that need one to compute.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral detail beyond that: the cost equivalence (same 148 credits), partial success with error listing (_metric_name_errors and _supported_metric_names), plan-level requirements for formula_override, and the effect of light_weight_mode. 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 dense but every sentence adds value: scope, timing, partial success, flags, endpoint, and plan requirements all in one paragraph. It is front-loaded with the primary purpose and usage, and no filler or redundancy exists.

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?

With 8 parameters (2 required) and no output schema, the description covers the essential aspects: what it returns, how errors surface, optional flags, plan gates, and a cross-reference to a sibling. For an agent that needs to call this correctly, nothing crucial is missing.

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?

Although schema description coverage is 100%, the description enriches several parameters: metric_names is explained with a catalog example and contrast to non-catalog labels, light_weight_mode is contextualized ('strip per-metric audit fields'), and formula_override has a concrete example plus a plan requirement. This exceeds the baseline 3 by adding actionable semantics.

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

Purpose5/5

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

The description states a specific verb ('Fetch'), a concrete resource ('computed metrics'), and scopes it to a single metric_group_id. It explicitly distinguishes itself from get_metrics_bundle by its purpose ('keep the response small when you already know the names'), which clearly differentiates it from the sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool ('when you already know the names') and references the sibling get_metrics_bundle, implying when the alternative is preferable. It also clarifies partial success behavior and that the same flags as get_metrics_bundle apply, giving the agent enough context to decide and invoke correctly.

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

All AkkruData toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources