bigapi

by BiGapi-2026

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: account/usage, rendering, PDF operations, and image operations are clearly separated. Even similar tools like get_usage, get_balance, and get_pricing have clearly different focuses.
Naming Consistency3/5
There are several naming conventions mixed together: get_* and set_* for account management, bare verb 'render', and noun_verb patterns like pdf_merge and image_process. Each subgroup is internally consistent, but the overall set lacks a single predictable pattern.
Tool Count5/5
13 tools is a well-scoped set for a utility API covering account management, rendering, PDF manipulation, and image processing. Each tool earns its place and there is no obvious bloat.
Completeness4/5
The tool surface covers account lifecycle basics, usage/cost monitoring, rendering, a solid set of PDF operations, and common image tasks. Minor gaps like PDF text extraction or key revocation exist, but they are not core to the apparent purpose.
Average 3.6/5 across 13 of 13 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses pricing (1 cent) and lists operations, but omits critical behaviors such as the default metadata stripping (implied by keep_metadata default false but not stated), output handling, destructive nature, or any authentication requirements. This is a serious gap for a mutation tool.
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 that efficiently lists all operations and the cost, with the key information front-loaded. There is zero wasted text, and it is well-structured for quick scanning.
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?
For a tool with 14 parameters, nested objects, and no annotations, this description is severely under-specified. It omits the required 'file' parameter, output_path behavior, defaults for fit/quality/watermark options, and any return format. The agent would struggle to use this tool correctly without additional external knowledge.
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?
With only 14% schema coverage, the description must compensate for undocumented parameters. It enumerates operations but does not map them to specific parameters (e.g., 'resize' to resize_width/height and fit, 'compress' to quality). It provides a high-level overview but fails to explain parameter semantics like the 'fit' enum or 'rotate' auto mode, leaving too much to inference.
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 performs image manipulations (resize, crop, rotate, convert, compress, strip EXIF, watermark) in one call. This distinguishes it from PDF tools and image_info (which likely only reads metadata), but it does not explicitly differentiate from image_info or other image-related tools, so a 4 rather than 5.
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. The only hint is 'in one call', suggesting combined operations, but no explicit use cases or exclusions (e.g., 'use image_info for metadata-only tasks'). An agent has to infer usage from the operation list.
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 of explaining behavior. It reveals that rotation is the operation, but does not mention what happens to the output file, whether it overwrites input, how idempotency_key behaves, or what errors or limitations exist.
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 short and front-loaded, stating the core operation first and keeping the price note to a single word. However, it is too sparse to compensate for the missing parameter and behavioral 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?
With five parameters, no output schema, and no annotations, the description is incomplete. An agent cannot reliably determine how to specify pages, where the output goes, or what the response will look like, making this inadequate for confident 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 description coverage is 0%, and the description does not explain parameters such as pages, output_path, or idempotency_key. The angle parameter is partially covered by the description, but the meaning of page-range syntax and output behavior is left entirely to inference.
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 operation: rotating PDF pages, with the supported angles enumerated. It distinguishes itself from sibling tools like pdf_merge, pdf_split, and pdf_compress by naming the specific transformation.
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 about when to choose this tool over alternatives, nor about prerequisites, page-range syntax, or cost beyond the terse '1 cent.' The usage context is implied by the tool name and angle options rather than explicitly 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?
No annotations are present, so the description must carry the full behavioral burden. It discloses one useful trait: the 1-cent cost. But it does not say what happens to the original file, whether output is returned or written to output_path, whether the API mutates anything, or any quotas/limits. This is insufficient for a tool with zero annotation support.
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 compact and front-loaded: the operation comes first, followed by high-value range syntax and cost. No wasted words. Retaining the cost line and range example is useful, though a sentence explaining output_path would add much more practical value.
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 tool with four parameters, no output schema, and zero annotations, this annotation is not complete enough to allow safe and accurate invocation. The agent must infer output_path requirements and idempotency semantics, and the description gives no clue how the extracted PDF is returned or saved. The helper page extraction is clear, but the surrounding operational details are missing.
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 only explains the pages parameter through an example range. It does not clarify that file is a PDF path, what output_path should be, or what idempotency_key does. With four parameters remaining largely undocumented, the description fails to compensate for the schema's lack of description.
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 opens with a clear verb and resource combination: 'Extract pages from a PDF.' The page-range example makes the operation concrete and unambiguous, and it differentiates this tool from siblings like pdf_merge, pdf_rotate, and pdf_compress, which do not extract subsets of pages.
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 guidance about when to choose this tool over its alternatives, and no conditions for when not to use it. The page-range syntax implies a usage flow, but the description never states how to decide between pdf_split and pdf_rotate, pdf_merge, or pdf_to_images. That leaves much of the tool-selection work 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?
With no annotations, the description carries the burden.
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?
Single sentence, front-loaded with purpose, and efficient. The cost note is a nice extra.
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 description covers what the tool does but lacks detail on input format and return structure. Without annotations or output schema, the agent lacks full context on how to call it and what to expect, though the simplicity keeps it from being severely incomplete.
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 one string parameter 'file' with no description (0% coverage), and the tool description does not clarify what 'file' means (path, URL, base64, etc.). The agent is left to guess the expected input format.
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 reads image metadata (format, dimensions, color space, EXIF/ICC presence) with a specific verb
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 description does not provide any guidance on when to use this tool versus alternatives like image_process or the PDF tools. No exclusions or recommendations are given, so an agent is left to infer from the purpose 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 provided, the description carries the full burden of behavioral disclosure. It transparently discloses a cost per call ('1 cent') and explains the trade-offs among the compression levels (smallest vs. largest, quality). However, it does not describe whether the input file is modified, whether output_path is required, or what the operation returns, which limits transparency.
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 extremely concise, using three short sentences to cover the core action, the main parameter options, and the cost. The purpose is front-loaded in the first phrase, with supporting details following in a logical order. Every sentence adds information without redundancy.
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?
This is a 4-parameter tool with no annotations and no output schema, so the description needs to be relatively complete. It covers the action, levels, and cost, but omits how the output file is named or returned, and the role of 'idempotency_key'. The absence of any mention of 'output_path' or the result format means an agent cannot fully determine correct invocation without additional assumptions.
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 input schema has 0% description coverage, so the description must compensate. It provides meaningful semantics for the 'level' parameter, mapping each enum value to a size/quality trade-off and identifying the default. However, it gives no semantic information for 'file', 'output_path', or 'idempotency_key', leaving those parameters under-specified.
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 states a specific verb ('Shrink') and resource ('a PDF'), which directly names the operation. It also enumerates four distinct compression levels, further clarifying what the tool does. This distinguishes it clearly from sibling PDF tools like merge, split, rotate, and image conversion.
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 description provides no guidance on when to use this tool over its siblings (e.g., pdf_merge, pdf_split). It does offer level-specific advice ('ebook... good for sharing'), but that addresses parameter selection, not tool selection. There are no explicit exclusions or alternatives mentioned.
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 must fully disclose behavioral traits. It does state the temporal scope (this month) and grouping, but it omits whether the operation is read-only, any authentication requirements, error conditions, or the structure of the response. This is minimal behavioral disclosure for a tool with no structured metadata.
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 short sentence, front-loaded with the key information: what it returns (operations and cost), the scope (this month), and the grouping. There is no fluff or redundancy, making it highly efficient.
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 low complexity (no parameters, no output schema), the description is adequately complete. It tells the agent what the tool returns and the grouping. It could be improved by a note on read-only behavior, but for a simple retrieval tool it is sufficient.
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 schema is empty and there is nothing to describe. Per the rubric, 0 parameters gets a baseline of 4. The description adds no parameter details (since none exist), and that is appropriate.
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 purpose: it returns operations and cost for the current month, grouped by operation. This specific verb, resource, and scope distinguish it from siblings like get_balance (which likely returns a balance) and get_pricing (pricing info), making it unambiguous for an agent to select.
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 that this is for month-to-date usage, nor does it name any sibling tools as alternatives. An agent would have to infer usage context, which is not ideal.
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 full burden. It discloses that it returns the local output path and mentions a cost of 1 cent, which is helpful. However, it does not mention other behavioral aspects such as authentication requirements, overwrite behavior, or input validation.
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 concise and front-loaded with the core action, and it includes useful cost information. It uses three short sentences without fluff, though it could be slightly more structured to separate behavior from usage.
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 14 parameters and no output schema, the description is incomplete. It does not explain parameter interactions, defaults beyond the format default, or constraints such as mutual exclusivity of html, markdown, and url. The description is not adequate for an agent to call the tool correctly without inspecting the schema.
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?
With schema description coverage at 50%, the description does not compensate for the undocumented parameters. It only mentions the input types (HTML, Markdown, URL) but does not explain parameters like format, page_format, landscape, margins, or PNG-specific options. The description adds minimal value 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 explicitly states the tool renders HTML, Markdown, or a URL to a PDF (default) or PNG file, which clearly defines the primary action and output. It distinguishes itself from sibling tools like pdf_merge and pdf_split by focusing on content generation rather than PDF manipulation.
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 provides clear positive use cases (reports, invoices, offers, documentation, screenshots) but does not explicitly mention when not to use it or name alternative tools. It implies usage but lacks exclusions, so it falls short of the top score.
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, and it does add useful context: local paths, ordered input, and a per-operation cost of 1 cent. However, it does not clarify overwrite behavior, what happens to the original files, or how the merged result is delivered.
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 extremely short and front-loaded. The core action comes first, followed by the key parameter detail and cost, with no filler or 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 simple merge operation, the description covers the main input and pricing, but it leaves the optional `output_path` and `idempotency_key` semantics unexplained. Given that there is no output schema and no annotations, an agent still lacks some information needed to understand the full contract.
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 description adds value for the `files` parameter by reinforcing local paths and ordering, but it says nothing about `output_path` or `idempotency_key`. Since schema description coverage is only 33%, the description must compensate for those undocumented parameters, and it does not.
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 states a specific verb and resource: merging two or more PDFs into one. It also specifies local paths and ordering, which makes the tool distinct from siblings like pdf_split and pdf_compress.
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 intended use case is clear: combining multiple local PDFs in a specific order. It doesn't explicitly spell out when not to use it or mention alternatives, but the context is unambiguous enough for an agent to select it over siblings.
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 burden of behavioral disclosure. 'Show' implies a read-only operation, and the listed fields indicate what information is returned. However, it does not explicitly state that the call is non-destructive, requires no arguments, or that it does not consume free operations.
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?
A single, compact sentence that front-loads the action and lists all relevant result fields. Every word earns its place with no redundant framing.
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?
For a no-parameter getter with no output schema, the description names all the returned data dimensions it can. It does not describe units or response format, but those are minor gaps for a simple balance query, and the listed fields provide enough context for an agent to invoke the tool correctly.
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 baseline for zero-parameter tools is 4. The description accurately implies no inputs are needed by describing what the configured key's balance is, so no parameter documentation gap exists.
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 identifies a specific verb ('Show') and resource ('balance'), and lists the concrete fields returned: credit, free operations remaining, monthly cap, and spend. This clearly separates it from get_usage and get_access in meaning.
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 this is the tool to call when checking account/quota balance, but it does not explicitly state when to prefer it over get_usage or get_access, nor does it mention any alternative tools. Usage context is adequate but not deeply instructive.
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?
With no annotations, the description carries behavioral disclosure itself: it discloses the default format, the single-page vs multi-page output behavior (image file vs ZIP), and the cost ('1 cent'). This is useful beyond the schema. It stops short of stating whether the source PDF is modified or how the file is returned, so not a perfect 5.
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?
Two terse sentences front-load the core action and output, then add behavioral and cost details. Every clause earns its place and there is no repetition of schema fields.
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?
It covers the high-level outcome and pricing, and the no-output-schema gap is partially addressed by saying what artifact is returned (image or ZIP). However, it omits how the returned file is delivered/represented in the response and gives no guidance on the many parameters, so an agent could not complete nuanced calls correctly from this text alone.
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 needed to compensate for 8 undocumented parameters, but it only clarifies the format default. It does not explain dpi, quality, page ranges, output_path, or idempotency_key, leaving an agent to infer their meaning from parameter names alone.
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?
States a specific verb ('Render'), resource ('PDF pages'), and output ('JPEG (default) or PNG images'), clearly distinguishing it from generic siblings like render and from pdf_merge/pdf_split. The use-case example reinforces when this tool is appropriate.
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 a clear usage context ('to look at a document with a vision model') that tells an agent when the tool is applicable. It does not name alternatives or add when-not guidance, so it falls short of the explicit 5-level bar.
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 must disclose behavior itself. It states the directional effect, default value, unit, and safety purpose, but it does not say whether the change applies immediately, how it interacts with existing usage, or what happens when the cap is reached. This is adequate for a simple setter but not richly transparent.
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?
Two short sentences, no filler. The action and default value are front-loaded, and the rationale ('Protects against runaway loops') earns its place by giving context.
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?
For a tool with one required parameter and no output schema, the description gives enough to call it correctly: what to modify, the unit, a default, and the purpose. Remaining gaps around immediate effect or what 'configured key' refers to are secondary for correct invocation.
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 description coverage is 0%, but the description adds crucial meaning by clarifying that the parameter is expressed in cents and by giving the default as 1000 cents = €10. This helps the agent understand monthly_cap_cents beyond the raw integer 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 names a precise action ('Raise or lower'), a precise resource ('monthly spending cap of the configured key'), and a unit (cents), and adds a functional default. It is clearly distinct from the sibling getters and document/image tools.
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 use for controlling spend and mentions protection against runaway loops, but it never explicitly states when to use this tool versus alternatives or conditions under which it should not be used. Since no sibling provides cap-setting, the guidance is inferred rather than explicit.
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?
Despite having no annotations, the description discloses cost, free tier, local storage, dependency of other tools, and the one-time call expectation. It does not cover behavior on repeat calls or response/error format, so it is not fully transparent but far above average.
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?
Three sentences cover the purpose, pricing, storage, and invocation timing with no fluff. Key details are front-loaded and every sentence contributes 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?
With one optional parameter and a clear handle, the description explains everything needed to call the tool correctly: why, when, what it costs, where the key goes. The return format is left out, but since the key is stored locally and used by other tools, that is not essential to the agent.
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 only parameter is 'name', and the input schema already documents it fully as an optional label with an example. The description adds no additional parameter guidance, but with 100% schema description coverage the baseline score of 3 is appropriate.
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 ('Get') and resource ('bigapi API key') and clearly states the outcome: a locally stored key usable by all other tools. This distinguishes it from sibling billing/introspection tools like get_usage and get_balance.
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 says exactly when to call it: 'Call this once if no key is configured.' It also explains that the key is shared by all other tools, which implies when it is needed. It does not explicitly list exclusions or alternatives, but the guidance is direct enough for an agent to decide.
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?
With no annotations provided, the description carries the behavioral burden. It tells the agent this is a read-only, machine-readable data retrieval operation returning current pricing, not a human-facing report or a mutating action. It does not mention auth or rate limits, but those are less critical for a simple pricing lookup.
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 filler. The key facts — 'current', 'price list', 'bigapi.dev', and 'machine-readable' — are front-loaded and each adds meaningful 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?
For a zero-parameter, read-only pricing tool, the description gives enough context to select and invoke it correctly. There is no output schema, but 'price list' is self-explanatory and 'machine-readable' signals the expected output form. Auth behavior is not disclosed, but that is a minor omission for this 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?
The input schema has zero properties and schema description coverage is 100%, so there are no parameters to document. The description appropriately does not invent parameters or imply that arguments are needed, which is correct for this tool.
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 returns the current price list for bigapi.dev, using a specific resource ('price list') and operation ('get'). It also distinguishes itself from siblings like get_usage, get_access, and get_balance, since none of those named tools are explicitly about pricing.
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 the correct use case: whenever the agent needs the current pricing information for bigapi.dev. It does not explicitly list alternatives or exclusions, but the use case is unambiguous and the zero-parameter nature of the tool reduces the risk of misuse.
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:

[![bigapi-mcp MCP server](https://glama.ai/mcp/servers/BiGapi-2026/bigapi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/BiGapi-2026/bigapi-mcp)

Score Badge

Copy to your README.md:

[![bigapi-mcp MCP server](https://glama.ai/mcp/servers/BiGapi-2026/bigapi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/BiGapi-2026/bigapi-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/BiGapi-2026/bigapi-mcp'

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