jb_gateway_mcp

by jitheshb83

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.3.1
Disambiguation5/5
Each tool has a clear, distinct purpose within its domain: ping for health checks, gmail for email operations, calendar for event operations, and drive for file operations. There is no overlap between tools.
Naming Consistency4/5
Most tools follow a consistent <domain>.<action>_<object> pattern (e.g., gmail.list_messages, drive.read_file), making them predictable. The lone 'ping' deviates slightly, but it is a common utility and does not disrupt overall readability.
Tool Count5/5
Eight tools are well-scoped for a gateway integrating three services (Gmail, Calendar, Drive) plus a health check. Each tool provides essential functionality without unnecessary bloat.
Completeness3/5
The set covers core retrieval and creation actions (list, read, send, create) but omits update/delete operations for all domains. For a gateway, basic access is present, yet users cannot modify or remove resources, which is a notable gap.
Average 3.1/5 across 8 of 8 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only says 'create', which is already obvious from the name. It does not mention side effects, authentication requirements, output behavior, or error conditions, making it effectively a tautology.
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 with no wasted words. It is easy to parse and understand at a glance, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 required parameters, no parameter documentation, no annotations), this description is severely incomplete. It does not explain ISO date formats, how to identify an account or calendar, or what the tool returns, leaving the agent with almost no operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 required parameters with 0% description coverage, and the tool description adds no parameter-level information. The agent is left without any explanation of what 'account', 'calendar_id', 'summary', 'start_iso', or 'end_iso' mean or how they should be formatted.
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 the tool's action ('create') and resource ('a new calendar event'), which separates it from calendar.list_events and other read-only siblings. However, it adds no details beyond the tool name itself, so it is clear but not very descriptive.
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 about when to use this tool versus alternatives. There is no mention that this is the write counterpart to calendar.list_events, nor any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 not mention whether the operation is read-only, whether it returns message metadata or full bodies, or any effects like marking messages as read. The description is minimal and lacks any safety or side-effect information.
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 gets to the point quickly. However, it is under-specified, but conciseness itself is fine.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 values are covered, but the description lacks usage context, alternatives, parameter details, and behavioral caveats. Given the sibling tools include read_message and send_message, more guidance is needed to understand when listing is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptive coverage for parameters, and the description only hints that 'query' filters results. It does not explain the Gmail search query syntax, the format of the 'account' parameter, or their defaults and constraints.
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 the tool lists Gmail messages for an account, with optional query filtering. The verb 'list' differentiates it from sibling tools like read_message and send_message, though it does not explicitly distinguish its role. The scope 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?
No guidance is provided on when to use this tool versus gmail.read_message or calendar/drive tools. It only mentions optional query filtering, without any context such as 'use this to search messages' or exclusions.
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, the description carries the full burden of disclosing behavioral traits. It notes that IBANs are masked, which is useful, but fails to mention that this is a read-only operation, any authentication requirements, or potential limitations such as pagination or data format.
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 immediately conveys the core function. It is concise with no filler, which is appropriate for the tool's simplicity, even though it sacrifices some explanatory detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four required parameters, no annotations, and no parameter documentation. The description is too sparse to provide adequate context for correct invocation, such as expected date formats, what 'details' means beyond counterparty, or how this differs from the summary tool. The presence of an output schema does not compensate for lack of usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description provides no additional meaning for any of the four required parameters (date_from, date_to, account_uid, institution). The agent receives no help understanding formats, semantics, or relationships between parameters.
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 the tool lists transactions and specifies the added detail (counterparty name/description). It distinguishes itself from the sibling 'list_transactions_summary' by implying a more detailed view, though it does not explicitly name the sibling or contrast the difference.
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 about when to use this tool versus alternatives. The description does not mention the summary variant or other sibling tools, and offers no exclusions or context about appropriate use cases.
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, the description carries the full burden of disclosing behavioral traits. It only states the action 'send' without mentioning side effects, authentication requirements, rate limits, or what happens after sending. This is insufficient for an agent to understand the tool's behavior beyond the obvious.
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 concise sentence that front-loads the core purpose. It contains no filler words or redundant information. However, it is so brief that it sacrifices necessary detail, which is a trade-off rather than a pure strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four required parameters and no annotations, the description is incomplete. It does not explain how to use the parameters, any prerequisites, or side effects. The presence of an output schema is helpful but does not compensate for the lack of operational context. The description is far from sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not: the four required parameters (account, to, subject, body) are not mentioned at all. The only hint is 'from an account', which vaguely relates to the account parameter but provides no semantics.
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 the verb 'send' and the resource 'email', and the phrase 'from an account' adds scope. It distinguishes itself from sibling tools like list_messages and read_message by indicating a write operation. However, it could be more specific about what 'account' refers to and any additional capabilities.
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 guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The only hint is the tool name and siblings, but the description itself offers no usage direction.
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 carries full behavioral disclosure burden. It only states that it gets balances, but does not explicitly confirm read-only behavior, authentication requirements, or any nuances of 'current/available' (e.g., real-time or cached values). The description adds minimal transparency beyond the tool name.
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 a single concise sentence of nine words, directly stating the tool's purpose without filler. Structure is front-loaded and clear.
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 output schema exists, so return values are likely documented elsewhere. However, the description lacks key context such as how to obtain account_uid (via bank.list_accounts), whether both current and available balances are always returned, and any prerequisites. With no annotations, the description is only minimally complete for a simple getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the parameters (institution and account_uid) at all. It adds no meaning beyond the property names, leaving the agent without clarity on expected formats, required relationships, or how the parameters are used to identify the account.
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 uses the specific verb 'Get' and identifies the resource as 'current/available balances for a bank account,' which clearly distinguishes it from sibling tools like bank.list_accounts that list accounts rather than balances. The scope is explicit and unambiguous.
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 given on when to use this tool versus alternatives. It does not mention that account_uid can be obtained from bank.list_accounts or clarify when get_balance is preferred over other bank tools. Usage context is entirely implied rather than stated.
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, the description carries full burden of behavioral disclosure. It only states 'List Drive files matching a query' and does not mention pagination, account requirements, query syntax, or whether it returns metadata or content. This is insufficient for a tool with a required account parameter.
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 a single, front-loaded sentence with no fluff or repetition. It earns its place by conveying the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and a required account field, the description is too sparse. Even with an output schema, it does not provide enough context about query syntax, pagination behavior, or what kind of file metadata is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only implies the 'query' parameter via 'matching a query'. It fails to explain the required 'account' parameter or the 'page_size' parameter, leaving their semantics undocumented.
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 ('List') and resource ('Drive files') with a qualifier ('matching a query'). It is specific and distinct from sibling tools like drive.read_file, which reads file content rather than listing files.
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, nor when not to use it. It does not mention relationship to drive.read_file or other siblings, and no usage context is given.
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?
Annotations are absent, and the description only states 'read', which implies a non-destructive operation but does not mention auth requirements, rate limits, or limitations (e.g., binary files vs text). No additional behavioral context provided beyond the basic action.
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?
One sentence, front-loaded with verb 'read', no waste. It efficiently conveys the core purpose without irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description provides core purpose, but lacks details about supported file types, output structure, or relationship to sibling tools. Output schema exists but is not referenced. Given no annotations and minimal schema, more context is needed for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has two required parameters (account, file_id) with no descriptions. Description does not explain what account refers to or how to obtain file_id. With 0% schema description coverage, the description fails to compensate for the lack of parameter details.
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?
Description states 'Read metadata and text content of a Drive file.' This clearly identifies the tool's purpose as reading a specific Drive file, distinguishing it from sibling drive.list_files which lists files. Verb 'read' is specific and the resource is explicit.
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 mention of when to use this tool versus alternatives. Does not indicate that drive.list_files should be used to obtain file_id, or that this is for reading content after listing. No explicit guidance on usage context or prerequisites.
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 responsibility for behavioral disclosure. It does reveal that returned IBANs are masked, implying a privacy-aware read operation. However, it does not mention authentication, rate limits, pagination, or whether all accounts are returned at once. The 'List' verb implies read-only, but this is not explicit.
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 a single, succinct sentence that front-loads the action 'List linked bank accounts' and appends a valuable clarifying detail about masked IBANs. No wasted 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?
Given the tool's simplicity (one parameter, output schema exists), the description covers the basic purpose but lacks usage guidance and parameter semantics. It is minimally adequate but leaves room for confusion about when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'institution', has 0% schema description coverage. The description says 'for an institution' but does not define what an institution is, what format it should take, or provide examples. It essentially repeats the parameter name, adding minimal semantic value.
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 verb 'List', the resource 'linked bank accounts', and the scope 'for an institution' with the detail '(masked IBAN)'. This distinguishes it from sibling tools like get_balance or list_transactions, which have different purposes.
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, and there are no prerequisites or exclusions mentioned. The phrase 'for an institution' hints at a required context but does not explain the intended use case or relationship to other bank tools.
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 provided, the description carries the burden of behavioral disclosure. It does disclose the limited field set, but it does not mention pagination, ordering, authentication requirements, or whether all transactions in the range are returned. For a simple read operation, this is minimally adequate but not rich in context.
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 a single, front-loaded sentence that wastes no words. It conveys the core purpose and the key limitation in a compact manner, making it easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four required parameters with no descriptions, no annotations, and a sibling with overlapping scope, the description is too sparse. It fails to provide guidance on how the tool fits into a workflow, what distinguishes it from the detailed version, or any security/access considerations. The presence of an output schema mitigates the need to explain return values, but the description still leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameters. It only implies 'date range' for date_from/date_to, leaving institution and account_uid entirely unexplained. This partial coverage is insufficient given all four parameters are required.
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 lists transactions for a date range and specifies the exact fields returned (date, amount, currency only). This directly distinguishes it from the sibling tool 'bank.list_transactions_detailed' through the word 'summary' and the explicit 'only' constraint.
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 phrase 'date, amount, currency only' implies a summary use case, which contrasts with the detailed sibling. However, it does not explicitly state when to use this tool versus bank.list_transactions_detailed, nor does it mention any prerequisites or exclusions, leaving the choice to inference.
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 burden of behavioral disclosure. It adds the 'upcoming' filter, which is not present in the schema, but it does not mention pagination, timezone handling, or whether recurring events are expanded. This is a modest addition beyond the schema.
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 a single sentence with no redundant phrases. It is front-loaded with the verb and resource, making it immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are 3 parameters, no annotations, and a schema coverage of 0%, the description is too sparse to provide complete context. It omits essential details about the required 'account' parameter and the behavior of 'max_results', leaving the agent uncertain about how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the meaning of 'account', 'calendar_id', or 'max_results' beyond what parameter names suggest. The 'account' parameter is especially ambiguous, and max_results' default limit is not mentioned.
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 it lists upcoming events, using a specific verb ('list') and resource ('events on a calendar'). This distinguishes it from sibling tools like calendar.create_event and other domain tools (gmail, drive).
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 implies usage for viewing future events but provides no explicit guidance on when to use it versus alternatives such as calendar.create_event. There are no exclusions or alternative tool mentions, so the usage context is only implicit.
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 carries the full burden. It does not disclose whether reading affects read status, auth requirements, or other side effects. It only states what is returned, which is minimal.
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 one concise sentence, front-loaded with the action and outcome. It conveys the necessary information without wasted 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 simple read tool with an output schema, the description is adequate to convey the core function. However, it misses behavioral context like auth scopes and potential limitations (e.g., body truncation), making it minimally complete but not fully rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters beyond their names. 'account' and 'message_id' are not defined; the description only clarifies the tool's purpose, not the expected parameter values or formats.
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 uses a specific verb ('Read'), a resource ('Gmail message'), and specifies content ('subject/from/snippet/body'). It clearly distinguishes from sibling tools like gmail.list_messages, which lists multiple messages, and gmail.send_message, which sends.
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?
The description clearly implies when to use: when a single Gmail message's content is needed. It does not explicitly state alternatives or exclusions, but the sibling tool list provides context, and the 'single' scoping is explicit.
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 provided, the description carries the full burden of behavioral disclosure. It discloses the lack of transaction detail, which is a behavioral trait, but it does not mention whether the operation is read-only, permission requirements, or specifics like whether pending transactions are included. This is a moderate disclosure at best.
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 a single sentence, front-loaded with the core action and resource. Every word earns its place, and it efficiently communicates the tool's primary purpose and one key limitation.
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?
An output schema exists, so return values need not be described. The tool is relatively simple and the description covers the main function, but it lacks definitions of terms like 'net' and does not clarify date inclusivity or account context, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the missing parameter guidance. The description only hints at 'date range' (mapping to date_from/date_to) but fails to explain institution or account_uid. This leaves the agent to infer their meaning without additional context.
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 uses a specific verb 'aggregate' and clearly identifies the resource (spending) and scope (date range). It also states 'no transaction detail', which helps distinguish it from sibling tools like bank.list_transactions_summary and bank.list_transactions_detailed.
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?
The description implies when to use this tool: when aggregate totals are needed. The phrase 'no transaction detail' provides a subtle exclusion, hinting that transaction-level tools should be used for details. However, it does not explicitly name alternatives or provide when-not-to-use guidance.
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 provided, the description carries the full burden. It discloses the core behavior (confirming reachability) and implies no side effects, but it lacks details on failure modes or prerequisites. The output schema presumably covers return values, which is acceptable.
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 a single, focused sentence that conveys the purpose without any unnecessary words. It is perfectly concise.
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?
The tool is simple, has no parameters, and an output schema exists, so the description provides the essential purpose. It would benefit from explicit usage context, but given the simplicity, it is sufficiently 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, so the description does not need to explain parameter semantics. The baseline of 4 is appropriate since there is nothing to add.
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's function as a smoke-test to confirm gateway reachability. It uses a specific verb ('confirming') and resource ('gateway process'), and it is distinct from sibling tools that operate on emails, calendars, or files.
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 phrase 'smoke-test' implies it should be used as a preliminary connectivity check, but the description does not explicitly state when to use it or mention alternatives. It leaves the timing and context to inference.
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:

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

Score Badge

Copy to your README.md:

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

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/jitheshb83/jb_gateway_mcp'

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