FinFam Financial Calculators

calculate_view

Read-onlyIdempotent

Run a financial calculation with the provided input values.

    Pass field values as a dict mapping field names to values.
    Use the types from get_view_signature: amount fields take numbers
    (e.g. 300000), percent fields take decimals (0.05 = 5%),
    count fields take integers, yesno fields take true/false.

    Args:
        owner_username: The view owner's username
        viewname: The view's URL slug
        inputs: Dict of field_name -> value for input fields

Input Schema

TableJSON Schema

Name	Required	Description	Default
`inputs`	Yes
`viewname`	Yes
`owner_username`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds the dependency on get_view_signature for input types, which is a behavioral nuance stagn. However, it does not explain output format or any side effects, but annotations cover safety. Meets baseline for annotation-covered traits.

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?

Purpose is stated up front, followed by a brief instruction list. No fluff; each sentence provides value. Slightly longer than necessary due to examples, but still efficient. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-param tool with nested inputs and no output schema, the description covers input usage well but fails to describe the return value or outcome of the calculation. It references get_view_signature for types, which helps, but there is no mention of what the tool returns (e.g., calculated result, errors). This is a notable gap given no output schema exists.

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 0% and the schema has no descriptions. The description thoroughly explains the inputs parameter structure, including the dict format and type mappings (numbers, decimals, integers, booleans) referencing get_view_signature. This compensates for the lack of schema descriptions and adds meaningful guidance.

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 ('Run a financial calculation') and the resource (a view with inputs). It distinguishes itself from sibling tools like get_view_signature or search_views by focusing on executing the calculation. No ambiguity.

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 instructions on how to structure the inputs dict accruing to field types, and references get_view_signature for type conventions. It gives clear context for usage but does not explicitly state when to use versus alternatives or exclusions. Lacks an explicit 'when not to use'.

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

All FinFam Financial Calculators tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose. The calculator tools cover search, contract, source, and execution, while the pulse tools cover current retrieval and search. No two tools overlap in function, so an agent can reliably select the correct one.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: calculate_view, get_pulse, get_view_signature, get_view_source, search_pulse, search_views. The verbs and nouns are clear, and the naming scheme is uniform across the set.

Tool Count5/5

Six tools is well within the ideal range for a focused server. Each tool addresses a distinct need within the financial calculator and news digest scope, making the count feel neither bloated nor sparse.

Completeness4/5

The calculator lifecycle is well covered: find a view, understand its inputs, optionally inspect its source, and run it. The pulse feature also covers current retrieval and historical search. A minor gap is the absence of a direct 'get view' operation independent of search, but this is workable via search_views.

Resources

Need Help?