ground-motion
Server Details
Measured ground motion per US address (NASA InSAR). Self-register, $0.40/report, misses free.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- james-sib/sibfly-api
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 9 of 9 tools scored. Lowest: 3.4/5.
Each tool targets a distinct function: account management, ground motion queries, batch processing, history, and Q&A. No two tools serve overlapping purposes, and descriptions clearly differentiate them.
Most tools use a 'verb_noun' pattern with verbs like get, register, buy, check, ask. However, 'check' is used for two tools (check_ground_motion, check_portfolio) while similar retrieval tools use 'get' (get_motion_history), creating a slight inconsistency in verb choice.
With 9 tools, the server covers account setup, credit management, ground motion queries (single, batch, history), and follow-up Q&A—a well-scoped set that earns each tool's place.
The tool surface covers the full lifecycle: account creation (register_agent), credit purchasing (buy_credits), balance/usage (get_account, get_usage), coverage checks (get_coverage), ground motion queries (check_ground_motion, check_portfolio), motion history (get_motion_history), and post-purchase Q&A (ask_inspector). No obvious gaps.
Available Tools
9 toolsask_inspectorARead-onlyInspect
FREE follow-up Q&A with the SibFly Inspector about a report you ALREADY BOUGHT (buy via check_ground_motion first). Ask what the numbers mean for foundations, staleness, seasonal swings, etc. It answers only from the report's numbers (never invents), and won't give buy/walk-away advice. Per-account message allowance applies.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | the address of a report already purchased on this account | |
| question | Yes | your question about the report |
Output Schema
| Name | Required | Description |
|---|---|---|
| reply | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide 'readOnlyHint: true', and the description adds that the tool 'never invents' answers, only uses the report's numbers, and won't give buy/walk-away advice. This enriches behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded with the key point of being free and requiring a purchased report. It could be slightly tighter by removing emphasis words like 'FREE' and 'ALREADY', but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of two parameters and an existing output schema, the description fully explains usage constraints, behavioral limitations, and prerequisites, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds context that 'address' must be for a purchased report and 'question' is about the report, but this largely restates what the schema already provides, offering only marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool is for FREE follow-up Q&A about a report already purchased via 'check_ground_motion'. It distinguishes itself from sibling tools by stating the prerequisite and constraints, such as not inventing numbers and not giving buy/walk-away advice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: after buying a report using 'check_ground_motion'. It also states what the tool does not do (no buy/walk-away advice) and mentions per-account message allowance, providing clear context for when to use or not use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buy_creditsAInspect
Get a machine-usable payment link to top up credits (requires your Bearer API key). method 'stripe' returns a card checkout_url; 'crypto' returns a BTC invoice_url + txn_id. Open/relay the URL to complete payment; credits land automatically afterwards — confirm with get_account.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | default stripe (card) | |
| amount_usd | Yes | 1 to 10000 (USD) |
Output Schema
| Name | Required | Description |
|---|---|---|
| method | No | |
| status | No | |
| txn_id | No | |
| amount_usd | No | |
| invoice_url | No | |
| checkout_url | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool generates a payment link, that completing payment results in automatic credit addition, and that it requires authentication. This adds context beyond annotations which indicate readOnlyHint=false and idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but 'has output schema: true'), the description adequately covers the tool's purpose, inputs, and the flow from link to payment to credit. It also references a sibling tool for confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The description adds further meaning: for 'method' it explains the return types (stripe->checkout_url, crypto->invoice_url+txn_id) and for 'amount_usd' it implies a range. This enriches the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a machine-usable payment link to top up credits, with specific verbs and resource. It distinguishes from sibling tools like get_account, which is used for confirmation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use each payment method ('stripe' vs 'crypto') and advises to confirm with get_account afterwards. It mentions the requirement of a Bearer API key, but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_ground_motionARead-onlyInspect
Measured ground motion (sinking/uplift) for a US address or lat/lon, in mm/year AND in/year, from NASA OPERA Sentinel-1 InSAR. Costs $0.40 from your SibFly credits; out-of-coverage / too-stale / too-low-confidence / fuzzy-geocode return FREE. Use the gate params to avoid paying for data you'd reject. dry_run=true is a FREE coverage+cost preview.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| since | No | YYYY-MM-DD; if no new data since this date, return free | |
| address | No | US street address | |
| compact | No | lean payload (fewer tokens) | |
| dry_run | No | FREE preview: coverage + would_cost + data age, no rate, no charge | |
| explain | No | add ground_brief: ~600 tokens of plain-English narration + FAQ (engine GL52 free tier / CL46 paying). Adds ~10s latency. Only set when a human will read the output; use ask_inspector for follow-up Q&A. | |
| max_age_days | No | if data older than this, return free instead of billing | |
| min_confidence | No | 0-1; below this, return free instead of billing | |
| require_significant | No | if the rate would be no_clear_trend (within its error bar), return FREE instead of billing — never pay for statistical noise |
Output Schema
| Name | Required | Description |
|---|---|---|
| engine | No | narration engine: GL52 (free tier) or CL46 (paying) |
| status | No | |
| cost_usd | No | |
| confidence | No | |
| ground_brief | No | only when explain=true |
| data_age_days | No | |
| near_threshold | No | |
| assessment_code | No | |
| credits_remaining_usd | No | |
| velocity_vertical_in_yr | No | |
| velocity_vertical_mm_yr | No | |
| velocity_uncertainty_mm_yr | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses cost ($0.40), free conditions (out-of-coverage, stale, low-confidence, fuzzy-geocode), gate params, dry_run behavior, and explain option latency (~10s). This goes beyond annotations (readOnlyHint) to fully inform the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus a brief note, all front-loaded with essential info. Every sentence adds value: purpose, cost, free conditions, and usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, 80% schema coverage, output schema existence, and sibling tools, the description covers pricing, free cases, gate params, dry_run, explain with latency, and hints at alternatives. It is fully adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema: it explains that lat/lon or address are valid inputs, describes gate params and their free-return behavior, and clarifies when to use explain. Even though lat/lon lack schema descriptions, the description covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool measures ground motion (sinking/uplift) for a US address or lat/lon in mm/year and in/year from NASA OPERA Sentinel-1 InSAR. It clearly distinguishes itself from siblings by mentioning coverage preview (dry_run) and paid data retrieval with gating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use gate params to avoid paying for unwanted data, and mentions dry_run for free preview. It implies alternatives like ask_inspector for follow-up Q&A, but does not explicitly name sibling tools for coverage or history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_portfolioARead-onlyInspect
Batch ground-motion for many US addresses in one call. Only covered addresses are billed ($0.40 each); misses and duplicate cells are free. If credits run out mid-batch the response status is 'insufficient_credits' and unbilled items are marked — top up (buy_credits) and retry them.
| Name | Required | Description | Default |
|---|---|---|---|
| addresses | Yes | up to 1000 US addresses (must be an ARRAY, not one string) | |
| max_spend_usd | No | hard budget cap: billing stops at this total; over-budget items come back skipped_for_budget |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| results | No | |
| summary | No | |
| credits_remaining_usd | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, but the description adds significant behavioral detail: per-address billing ($0.40), free misses/duplicates, batch interruption handling, and credit depletion behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first nails the purpose, the second covers billing and error handling. No redundant words; every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch, billing, errors) and the presence of an output schema, the description covers key behavioral aspects. It omits details on the output format but provides enough for correct invocation and error recovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reinforces the billing context for addresses and the budget-cap behavior for max_spend_usd, but does not add fundamentally new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('batch ground-motion'), resource ('many US addresses'), and distinguishes it from siblings like 'check_ground_motion' (single address) and 'buy_credits' (recharging). The title reinforces the batching concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch usage and provides explicit billing rules and error recovery steps (insufficient_credits → buy_credits and retry). It could be improved by directly contrasting with single-address check_ground_motion, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountBRead-onlyInspect
FREE: your SibFly credit balance, price per report, reports remaining, and top-up URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| top_up_url | No | |
| credits_usd | No | |
| price_per_report_usd | No | |
| reports_remaining_est | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that it is FREE and lists the returned fields. However, it does not disclose potential rate limits, authentication needs, or any side effects beyond the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that lists multiple items, which is concise. However, a structured list might improve readability. It is front-loaded with important info ('FREE').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and an output schema exists, the description adequately covers what the tool returns. It is complete for a simple account retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%, so the baseline is 4. The description does not need to add parameter information, as there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves SibFly credit balance, price per report, reports remaining, and top-up URL. It uses a specific verb and resource, and the 'FREE' tag helps differentiate from paid operations like buy_credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus siblings like buy_credits or get_usage. It does not specify any prerequisites or contexts where it is appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_coverageARead-onlyInspect
FREE pre-flight: is a US address/point covered, how stale is the data (data_age_days), and what a report would cost. Accepts ONE address/lat+lon, OR addresses[] (up to 1000, needs your Bearer key) to size a whole job before spending. Call this before spending.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| address | No | ||
| addresses | No | batch mode: size a whole job in one free call |
Output Schema
| Name | Required | Description |
|---|---|---|
| frame | No | |
| covered | No | |
| results | No | |
| summary | No | |
| data_age_days | No | |
| would_cost_usd | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint annotation: it is free, returns data age and cost, and supports batch mode for job sizing. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loaded with purpose and free status. Every sentence adds value without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description appropriately explains what the tool returns (coverage, data age, cost). It covers batch mode, free usage, and pre-flight context, making it complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite low schema description coverage (25%), the description compensates by explaining that lat+lon or address can be used singly, and addresses[] can batch up to 1000 items. It adds meaning beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking if a US address/point is covered, data staleness (data_age_days), and report cost. It distinguishes itself from siblings like 'check_ground_motion' or 'check_portfolio' by being a free pre-flight check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Call this before spending' and explains different input modes (single address/lat+lon or batch addresses with Bearer key). It gives clear context for when to use but does not explicitly mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_motion_historyARead-onlyInspect
Multi-year cumulative motion history for an address. Pass from_date and to_date (YYYY-MM-DD) to get the movement between two dates. Costs $0.40 (misses free). dry_run=true is a FREE preview (points + dates + cost, no data); max_age_days returns free instead of billing for stale data.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| address | No | ||
| dry_run | No | FREE preview: coverage + n_points + would_cost, no series, no charge | |
| to_date | No | ||
| from_date | No | ||
| max_age_days | No | if data older than this, return free instead of billing |
Output Schema
| Name | Required | Description |
|---|---|---|
| dates | No | |
| delta | No | |
| cum_mm | No | |
| status | No | |
| cost_usd | No | |
| credits_remaining_usd | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint), the description adds cost details ($0.40, free preview with dry_run, free for stale data via max_age_days). It explains that dry_run returns points, dates, and cost without data, and max_age_days avoids billing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with purpose, then date parameters, then cost and free conditions. Every sentence adds essential value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (0 required), 29% schema coverage, and an output schema, the description covers main inputs, cost policy, and free preview. It could clarify the relationship between lat/lon/address but sufficiently orients the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 29% schema description coverage, the description compensates by explaining from_date/to_date format (YYYY-MM-DD) and their role, dry_run and max_age_days behaviors, and location inputs (lat, lon, address). It adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Multi-year cumulative motion history for an address,' specifying the action and resource. It differentiates from sibling tools like check_ground_motion (current motion) and check_portfolio (portfolio analysis), though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: for motion between two dates, with examples of date format and cost conditions. It lacks an explicit when-not-to-use or alternative recommendations, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageARead-onlyInspect
FREE: your recent billed calls (line-item ledger with request_id, endpoint, address, cost) so you can reconcile spend against reports.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max rows, default 100, max 1000 |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | No | |
| spent_today_usd | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a read-only operation. The description adds the specific output fields but no further behavioral context such as side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with 'FREE', contains all essential information, and has no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the availability of an output schema (not shown but present), the description mentions the key fields. The single optional parameter is fully described. Minor missing context like authentication is acceptable for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the limit parameter with default and max values (100% coverage). The description adds no additional semantic information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies that the tool retrieves recent billed calls with line-item details (request_id, endpoint, address, cost) for reconciling spend against reports. This distinct purpose and verb 'get usage' differentiate it from sibling tools like buy_credits or get_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for spend reconciliation and labels it as 'FREE', but it does not explicitly state when to use this tool over siblings or any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_agentAInspect
FREE: create a new SibFly account and get an API key + free starter credits in ONE call — no human, no captcha, no card. Use this when you have no API key. SAVE the returned api_key and pass it as the Bearer token on later calls (MCP clients: set it as the Authorization header).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | a durable email address (disposable domains rejected) | ||
| password | No | optional; auto-generated and returned if omitted |
Output Schema
| Name | Required | Description |
|---|---|---|
| api_key | No | |
| password | No | |
| credits_usd | No | |
| reports_remaining | No | |
| price_per_report_usd | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, so the description's mention of 'create' aligns. It adds valuable context: the call is free, no human/captcha/card required, and it returns credits. It does not describe error handling (e.g., duplicate email), but given the annotations cover mutation behavior, the description sufficiently enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the key purpose ('FREE: create...') and immediately follows with usage context and post-call instructions. Every sentence serves a distinct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple registration tool with 2 parameters and an output schema (which likely describes the api_key), the description covers what the tool does, when to use it, and what to do with the result. It omits details like account verification or duplicate email handling, but these are not critical for basic invocation. More details could improve completeness, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed parameter descriptions (email: 'durable email address, disposable domains rejected'; password: 'optional, auto-generated if omitted'). The description adds no further parameter semantics beyond reinforcing that email must be durable and password is optional. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'create a new SibFly account and get an API key + free starter credits in ONE call'. It clearly identifies the verb (create), resource (account), and outcome (API key + credits). This uniquely distinguishes it from sibling tools like 'get_account' or 'buy_credits'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this when you have no API key.' It also instructs on what to do with the result: 'SAVE the returned api_key and pass it as the Bearer token on later calls.' This is perfect for avoiding confusion with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!