Skip to main content
Glama

Ask a source for numbers

numbers
Read-only

How a number is doing (sign-ups, visits, sales, a funnel, open tasks) over some days, weeks or months, as a reading and a chart: numbers from one of the project's sources, as Alcoven shows them to this person: a measure over some days, split by day, week, month or a field, with where the numbers come from and when they were fetched or counted; for a table or numbers a product sends, the day of the newest row or the time of the newest number, how often new ones should come, who keeps it and whether it has gone quiet. source: "this project" (counted now from what this person can open: its own open tasks, tasks added, done and past due, open and closed notes, what waits for agreement, agreements and changes, split by person or folder; and expectations, how the Expect lines whose date fell in the window came out, split only by mine for this person's own), a .source.md path, or a GitHub folder linked to the project (like app/), which offers releases, merged pull requests and commits. The answer ends with the same question written as a widget file. Takes a widget's path or § address and answers with that widget's own settings (shape, steps, days, comparison). The answer carries a chart view for apps that show interactive views, and the same numbers as text and data for every app.

Input Schema

NameRequiredDescriptionDefault
byNoday, week, month, or a field the source names.
sinceNoA date (2026-10-01), "28 days", "this month" or "this year". Default: the widget's own Since line when there is one, else 28 days.
sourceNoThe source: this project, a .source.md path, or a linked folder like app/. Not needed when widget is given.
widgetNoA widget's path, ending .widget.md, or its § address. The answer uses that widget's own lines, so source and measure are not needed.
compareNo"the period before", "last year" or "target 500".
measureNoA measure the source names, like sign-ups. Not needed when widget is given.
projectNoThe project's slug, from open_project, like acme. Not needed when a § address names the project, or when the person is on one project.

Output Schema

NameRequiredDescriptionDefault
byYes
okYes
urlNo
textYes
viewNo
as_ofNo
shapeNo
sinceYes
titleNo
untilYes
whereYes
funnelNo
widgetYes
addressNo
readingYes
measuresYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds substantive behavioral context: permission-limited source data ('what this person can open'), freshness/fetch details, widget-derived settings, and chart plus text/data output formats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very long and run-on, packing source types, widget behavior, and output formats into a dense paragraph. The content is relevant, but it is not front-loaded or easy to scan.

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 an output schema and annotations present, the description still supplies enough context about supported sources and answer shape for correct invocation. It is less complete on routing versus sibling tools, but adequate overall.

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 all seven parameters are documented in the schema. The description adds examples for source and widget and notes that widget supplies source/measure, but does not add much syntax beyond what the schema already provides.

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

Purpose4/5

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

The description identifies the resource (numbers from project sources) and operation (read/report a measure over time, with chart and text/data output), and enumerates source types. It does not contrast with siblings such as list, search, or why, but the core purpose 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 Guidelines2/5

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

There is no explicit when-to-use/when-not guidance and no mention of alternative tools. It describes widget and source modes, but leaves the agent to infer that this is for metrics/charts rather than, e.g., list or search.

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