Skip to main content
Glama
Sign In
grid402-mcp

grid402-mcp

by oliveiratc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

grid402_workdays

Calculates financial business days and projects ANBIMA maturity dates, or checks whether a specific date is a banking business day.

Instructions

Calcula dias úteis financeiros e projeção de vencimentos na convenção ANBIMA (D+0 exclusivo no início e inclusivo no fim) ou verifica se uma data é dia útil bancário.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "grid402_workdays"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoData pontual no formato AAAA-MM-DD para verificação de dia útil.
daysNoQuantidade inteira de dias úteis para projeção de vencimento (positivo para futuro, negativo para passado).
end_dateNoData de término no formato AAAA-MM-DD para contagem de intervalo de dias úteis.
start_dateNoData de início no formato AAAA-MM-DD para contagem de intervalo ou projeção de prazo.
payment_tx_hashNoHash opcional de transacao na Base Mainnet comprovando o pagamento de 0.0005 USDC caso nao utilize liquidacao automatica.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden, and it does disclose the non-obvious ANBIMA counting convention (D+0 excluded at the start, included at the end), which materially affects results. However, it omits that calls may require a 0.0005 USDC payment on Base Mainnet unless automatic settlement applies, and it says nothing about what the response looks like or how errors/edge dates are handled.

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?

One compact sentence with the core operation front-loaded and no filler. It is dense—the ANBIMA parenthetical is load-bearing but compresses two modes into a single clause, which slightly hurts scannability.

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 zero-required-parameter computation tool with no output schema and no annotations, the description should explain the three call shapes and what each returns. It covers the concepts but leaves mode selection and response shape implicit, and the paid-call requirement lives only in the schema, so an agent could under-plan a call.

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 already 100%, so the baseline is 3 and the schema documents every parameter's format and meaning. The description adds conceptual framing (interval counting vs projection vs single-date check) but does not explicitly tie those modes to start_date/days/end_date/date, so it adds no semantic detail 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 names a specific operation set: computing financial business days and projecting due dates under the ANBIMA convention, or checking whether a single date is a banking business day. That is far more specific than the tool name alone. It stops short of 5 because it never distinguishes itself from the sibling grid402_holidays, which an agent could easily confuse with a business-day check.

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?

Two operating modes are implied (interval/projection vs single-date check), but the description never states which parameters select which mode, nor when an agent should prefer grid402_holidays instead. Usage must be inferred by mapping the sentence onto the schema property names, which is possible but not guided.

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

Deploy Server

Other Tools