mesa-mcp

by BenyFridY

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.1
Disambiguation5/5
Each tool targets a distinct aspect of the financial domain: status check, spending summary, purchase listing, purchase detail, reconciliation verdicts, payer verification, and tax calculation. No two tools have overlapping purposes, and even the singular/plural pair (compra/compras) is clearly differentiated.
Naming Consistency4/5
All tool names are lowercase Portuguese nouns (e.g., gasto, compras, vereditos). The only deviation is status_do_livro, which uses underscores and is more descriptive. While the pattern is consistent in being noun-based, the mixed style (underscore vs. single-word) is a minor inconsistency.
Tool Count5/5
With 7 tools, the server is well-scoped for a financial reporting and reconciliation service. Each tool covers a necessary function without being overly granular or bloaty, fitting comfortably in the optimal 3-15 tool range.
Completeness5/5
The tool set covers the full read-only lifecycle for the domain: status checking, spending summaries, purchase listing and detail retrieval, three-way reconciliation, passport verification, and tax computation. There are no obvious gaps for the server's apparent purpose of audit and analysis.
Average 3.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 34 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It mentions ordering (most recent first) and the default limit, but does not state whether the operation is read-only, if there are side effects, or any authentication/rate-limit requirements. The tool appears to be a query operation, but that is not explicitly stated.
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?
The description is a single sentence that packs the core action, ordering, and all filter options, front-loading the main purpose. It is dense but not verbose, though the long list of estado values could be clearer with delimiters or bullet formatting.
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?
Given 6 parameters, no schema descriptions, and no annotations, the description covers the essential filter names and some allowed values, plus ordering and default. It does not explain the meaning of 'agente' and 'contem' in detail, nor explicitly confirm read-only behavior, but the existing output schema mitigates return-format gaps. Overall adequate but with notable omissions.
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?
The schema has 0% description coverage, so the description must compensate. It provides explicit allowed values for 'estado', examples for 'rede' (CAIP-2) and 'trilho' (x402/invoice/mpp/ap2), and a range/default for 'limite'. However, 'agente' and 'contem' are only named, with no added semantics beyond their titles, leaving gaps.
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 clearly states it retrieves book purchases, most recent first, and enumerates the available filters. It is specific about the resource (book purchases) and the operation (listing), but it does not explicitly contrast with sibling tools like 'compra' (singular) or 'gasto', leaving some ambiguity about when this tool is the right choice.
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?
No usage guidance is provided. The description lists filters but does not state when to use this tool versus alternatives, nor any exclusions or conditions. An agent would have to infer usage from the filter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that differences are never silent ('Uma diferença nunca é um gap silencioso') and that each verdict is explained, which is useful. However, it does not state whether this is a read-only operation, what data it reads, or any side effects. The behavioral transparency is partial, so a 2 is appropriate.
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?
The description is a single, front-loaded sentence that leads with the core purpose. It is concise and contains no redundant filler. The poetic phrasing 'Uma diferença nunca é um gap silencioso' adds a unique behavioral note without lengthening much. It's well-structured for a one-sentence definition.
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?
Given that the tool has no parameters and an output schema exists, the description reasonably explains what the tool does and the nature of its output (counts and explanations). However, it lacks explicit context about when to invoke it in a workflow and how it relates to the sibling tools. For a zero-param tool, it's adequate but not complete – an agent might not know if this is the right tool for a given task.
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?
The tool has zero parameters, so the baseline is 4 per the rubric. There is no parameter information to add, and the description doesn't need to compensate for schema gaps. The input schema is empty, so the description naturally covers all parameter aspects. No deductions are necessary.
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 clearly states a specific action – three-way reconciliation (pedido × autorização × chain) with a count by named verdict and explanation of each. This is more specific than a generic 'verdicts' name. However, it does not explicitly differentiate from sibling tools like status_do_livro or fiscal, so it's clear but not fully distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of exclusions, prerequisites, or context in which this reconciliation should be performed. The phrase 'feita AGORA' suggests immediacy but not a specific usage condition. The description completely lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses the default period logic and lists outputs, which is useful. However, it does not state whether the operation is read-only, whether it requires special permissions, or any errors/limits.
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?
A single dense sentence packs the purpose, outputs, and default behavior. It is front-loaded and efficient, wasting no words.
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 tool with two optional parameters, the description covers the essential behavior. It does not reference the output schema or mention edge cases, but given the simple interface it is adequate. Slightly more context on what 'veredito' means or typical use cases would help.
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?
The schema provides only names and nullability, with zero description. The description compensates by explaining the meaning of ano/mes and the default handling when omitted. This adds valuable meaning 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 clearly identifies the resource (fiscal competence data) and specifies the outputs (mainnet exits, R$ total via PTAX, and PF obligation threshold verdict). It is distinct from siblings like 'gasto' or 'compras', though it lacks an explicit verb like 'get'.
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?
The only usage guidance is that omitting year/month defaults to the current period. No mention of when to use this tool versus siblings, no scenarios, no exclusions. The agent is left to infer when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions the event chain, which indicates what the tool returns, but it does not explicitly state that the operation is read-only or disclose any side effects, permissions, or limitations. The lack of explicit safety or mutation info leaves the agent uncertain.
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?
The description is a single, efficient sentence that front-loads the core purpose. The phrase 'gaveta do blotter' is jargon that may confuse some agents, but it does not detract from overall brevity and structure.
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?
The tool has an output schema, so return value details are not required. The description mentions the event chain, which is a key part of the output. However, given the absence of annotations, it should more clearly indicate that this is a read-only operation or mention any prerequisites. It is adequate but leaves room for improvement.
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?
The schema provides no description for the 'rid' parameter (0% coverage). The description adds context by specifying that the rid comes from 'compras', which helps the agent understand its origin and format expectation. This provides minimal but useful semantic guidance beyond the schema.
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 identifies the tool as retrieving a specific purchase by rid and includes its event chain. It distinguishes itself from sibling 'compras' (which likely lists purchases) by focusing on a single purchase with detailed context. The verb is implied but the resource and scope are explicit.
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 description mentions 'vindo de compras' implying that the rid comes from the compras tool, giving context on when to use this tool. However, it does not explicitly state when not to use it or name alternatives beyond the implicit source. The guidance is implied rather than directly comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It implies a read-only summary operation and enumerates the aggregation dimensions, but it doesn't disclose pagination, whether the data is real-time or cached, or any limitations. The presence of an output schema covers return shape, so the gap is moderate.
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?
A single sentence that front-loads the core purpose (summary of spend in the whole book) and then lists the breakdown dimensions. It is compact and efficient, though the grouped list of dimensions is slightly dense and could benefit from clearer separation.
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?
An output schema is present, covering return values, so the description doesn't need to explain them. The dimensions of the summary are enumerated, making it adequate for a read-only aggregation tool. The main omission is behavioral context (caching, freshness) but that's minor given the output schema.
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?
With zero parameters, the schema trivially covers 100%, so there is nothing for the description to add about parameter semantics. The baseline of 4 for a zero-parameter tool applies, and the description's focus on what the summary contains is appropriate for a no-input query.
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 states a specific purpose: summarizing spend across the whole book, broken down by mainnet/testnet/invoice, rail, agent, and day. This clear resource (the whole book) and scope distinguish it from siblings like compras (purchases) and fiscal (taxes), though it doesn't explicitly contrast itself with them.
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?
No guidance on when to use this tool versus alternatives such as compras, compra, or fiscal. There is neither an explicit when-to-use nor a mention of when not to use it, leaving an agent to infer the appropriate context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that the operation is a re-verification performed offline and lists what is checked, implying a read-only action. However, it does not explicitly state that it has no side effects, nor does it mention permissions, error conditions, or what happens if verification fails.
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?
The description is a single sentence, efficiently conveying the action and the checks. It is not overly verbose or redundant. The structure is acceptable, though the colon-separated list could be slightly clearer, but it remains appropriately sized.
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?
Given the tool has no parameters and an output schema exists, the description covers the essential 'what' and 'how' reasonably well. It explains the purpose and the dimensions checked. However, it lacks any indication of when to invoke it relative to other tools and does not mention any prerequisites, so it is not fully complete.
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?
The tool has zero parameters, and the schema is empty with 100% coverage. Baseline for 0 params is 4. The description adds relevant contextual detail about what the call verifies and outputs, which complements the absence of parameters without needing to explain any.
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 states a specific action ('RE-VERIFICADOS offline') on a specific resource ('passaportes de pagador (F10)') and lists the checks performed (integrity, policy acceptance, reasons, metrics). It is clear enough to understand the tool's core function, but it does not explicitly distinguish it from sibling tools like 'fiscal' or 'vereditos' that might also perform verification.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, conditions, or exclusions. An agent would have no basis to choose this over a sibling beyond the name and vague purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: 'o livro nunca finge tempo real', informing the agent data may not be live. It also implies read-only by instructing to call before trusting numbers, but does not explicitly state it is side-effect-free. With annotations absent, this added context raises transparency, though it could be more explicit about non-mutation.
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 two sentences, front-loaded with the core 'what it reports', then a usage directive. No wasted words, efficient and structured. The dash provides a natural pause, and every clause carries necessary 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?
Given the tool has no parameters and an output schema (which likely details the return structure), the description covers the essentials: what it does, when to call it, and a important limitation. It could mention that it is read-only, but that is implied by the status-check nature. Overall, it is nearly complete for a simple status tool.
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?
There are zero parameters, so the schema fully covers them. The baseline of 4 applies. The description adds value by explaining what the tool returns (cursors, hash chain), which indirectly clarifies the tool's purpose, though it says nothing about parameters since none exist.
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 tool reports data freshness: 'cursores do coletor (bloco por rede) e a corrente de hash (seq/elos)'. This is distinct from sibling tools (gasto, compras, etc.) which likely return business data, not status. The verb 'status' and resource 'livro' are specific, and the purpose is unambiguous.
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?
It explicitly says 'Chame antes de confiar em qualquer número', giving a clear when-to-use. However, it does not mention when not to use it or compare it to alternatives. Since siblings are data-focused, the context implies this is a prefix check, but no explicit exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tercet MCP server](https://glama.ai/mcp/servers/BenyFridY/tercet/badges/card.svg)](https://glama.ai/mcp/servers/BenyFridY/tercet)

Score Badge

Copy to your README.md:

[![tercet MCP server](https://glama.ai/mcp/servers/BenyFridY/tercet/badges/score.svg)](https://glama.ai/mcp/servers/BenyFridY/tercet)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BenyFridY/tercet'

If you have feedback or need assistance with the MCP directory API, please join our Discord server