Measured ground motion per US address (NASA InSAR). Self-register, $0.40/report, misses free.
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.
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.
ask_inspectorAFREE 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 |
| Name | Required | Description |
|---|---|---|
| reply | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: it's free, answers only from report numbers, never invents info, and won't give investment advice. Annotations only provide readOnlyHint, so the description provides essential behavioral disclosure.
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?
Three sentences with key info front-loaded: FREE, follow-up, prerequisite. Every sentence adds value with no waste.
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 tool complexity (simple Q&A) and existence of output schema, the description adequately covers input constraints, expected behavior, and limitations (no invention, no advice). It is complete 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?
Schema coverage is 100% with both parameters described. The description reinforces the context (address must be for a bought report) but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate given high schema coverage.
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?
Description clearly states it's a follow-up Q&A tool for reports already bought via check_ground_motion. It specifies the exact resource (report) and action (asking questions), and distinguishes from siblings like check_ground_motion (buy) and other unrelated tools.
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?
Explicitly says when to use (after buying a report via check_ground_motion) and when not to use (no buy/walk-away advice). Also mentions per-account message allowance, setting clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buy_creditsAInspectGet 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) |
| Name | Required | Description |
|---|---|---|
| method | No | |
| status | No | |
| txn_id | No | |
| amount_usd | No | |
| invoice_url | No | |
| checkout_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=false and idempotentHint=false, the description carries the burden of disclosure. It explains that the tool returns a payment URL, credits land automatically after payment, and mentions the output per method. It does not mention potential side effects like link expiration or rate limits, but it does not contradict annotations and provides sufficient transparency for safe invocation.
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-loading the core purpose, then detailing the two methods and follow-up. Every sentence is informative and non-redundant. Perfectly concise for the complexity.
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 that output schema exists, the description need not detail return values, yet it briefly does. It covers parameter explanation, behavioral steps (get link, pay, credits land), and a confirm step. It also mentions authentication. For a tool with 2 parameters, this is highly complete.
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% (baseline 3). The description adds value by explaining how the 'method' parameter affects the output (stripe returns checkout_url, crypto returns invoice_url + txn_id) and implies the range for amount_usd. This enriches the parameter meaning beyond the schema alone.
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?
Description clearly states the tool's purpose: 'Get a machine-usable payment link to top up credits.' It specifies the verb 'Get' and the resource 'payment link', and distinguishes between two payment methods. It also mentions the requirement for a Bearer API key, leaving no ambiguity about what the tool does relative to siblings like 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 provides clear context for when to use the tool (to top up credits) and includes post-usage guidance to 'confirm with get_account.' It does not explicitly state when not to use it or list alternatives, but the purpose is distinct enough among siblings. The guidance is adequate though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_ground_motionAMeasured 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 |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses cost ($0.40), free return conditions (out-of-coverage, too-stale, too-low-confidence, fuzzy-geocode, dry_run, require_significant), and that dry_run is a free preview. This adds context beyond the readOnlyHint annotation, which already marks it as read-only.
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 brief yet comprehensive, starting with the core function, then cost, free conditions, and gate params. Every sentence adds value without redundancy. It is front-loaded with the most important information.
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 has 10 parameters and an output schema exists, the description covers all critical aspects: input options, cost, free scenarios, gate logic, explanation feature, and references sibling tools (ask_inspector). It provides sufficient detail for correct selection and invocation.
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 explains the purpose of key parameters (dry_run for free preview, explain for plain-English narration, require_significant to avoid paying for noise) and adds meaning to schema-covered params by describing their behavior (e.g., since: return free if no new data; max_age_days: return free if data older).
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 measures ground motion (sinking/uplift) for US addresses or lat/lon in mm/year and in/year from NASA OPERA Sentinel-1 InSAR. It distinguishes itself from siblings like get_coverage and get_motion_history by specifying the source and output units.
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 advises using gate params (dry_run, max_age_days, min_confidence, require_significant) to avoid paying for unwanted data. It contrasts explain with ask_inspector for follow-up Q&A and notes when to use explain (only when a human reads the output).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_portfolioABatch 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 |
| Name | Required | Description |
|---|---|---|
| status | No | |
| results | No | |
| summary | No | |
| credits_remaining_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses billing behavior, credit handling, and response status details, adding significant value beyond the readOnlyHint annotation. It fully informs the agent of important behavioral traits for this operation.
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, front-loaded with purpose, and each sentence adds value without redundancy. It is concise and 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 presence of an output schema, the description covers billing, errors, and retry logic adequately. It does not explain return JSON structure, which is acceptable due to the output schema. Slightly more context on input validation could be helpful but not necessary.
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%, but the description adds pricing context for covered addresses and explains the behavior of max_spend_usd (over-budget items marked). This provides meaningful semantic enrichment 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 states it is for batch ground-motion for many US addresses, which is a specific verb and resource. It implicitly distinguishes from siblings like check_ground_motion (likely for single addresses) but does not explicitly name alternatives.
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 clear context on when to use (for many addresses) and what to do on insufficient credits (top up and retry). It lacks explicit when-not-to-use cases but offers actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountAFREE: your SibFly credit balance, price per report, reports remaining, and top-up URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| top_up_url | No | |
| credits_usd | No | |
| price_per_report_usd | No | |
| reports_remaining_est | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds context that the operation is free and lists the returned fields, going beyond the annotation. However, it doesn't disclose any other behavioral traits like rate limits or authentication needs, but those are minimal for a read tool with no parameters.
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' and clearly lists all returned items. No wasted words, every element earns its place.
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 tool with no parameters and an existing output schema, the description is adequate. It explains the resource and key outputs. However, it could mention any prerequisites or authentication, but those might be inferred from context. The tool is simple, so completeness is high.
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 tool has zero parameters, so schema coverage is trivially 100%. The description adds value by explaining the output, which is beyond what the empty schema provides. Baseline for 0 params is 4.
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 returns SibFly credit balance, price per report, reports remaining, and top-up URL. This is a specific verb (get) and resource (account info), and it distinguishes from sibling tools like buy_credits or get_usage.
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?
No guidance is provided on when to use this tool versus alternatives like get_usage or check_portfolio. The 'FREE' label hints at cost implications but does not explicitly state when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_coverageAFREE 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 |
| Name | Required | Description |
|---|---|---|
| frame | No | |
| covered | No | |
| results | No | |
| summary | No | |
| data_age_days | No | |
| would_cost_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, so the tool is read-only. The description adds significant behavioral context: it's FREE, shows data age and cost, and batch mode requires a Bearer key. No contradiction with annotations. Could mention rate limits or authentication details, but the additions are valuable.
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?
Description is three sentences, front-loaded with 'FREE pre-flight', and each sentence adds essential information. No wasted words, and the important points (what it checks, how to use, when to call) are efficiently conveyed.
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 that an output schema exists (from context), the description does not need to detail return values, and it mentions what the tool returns (coverage, data_age_days, cost). It covers single and batch usage but misses potential error conditions or the exact limit of 1000 addresses. Still, it is fairly complete for a pre-flight check 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?
Schema description coverage is only 25% (only addresses has a description). The description compensates by explaining the purpose of lat+lon, address, and addresses parameters, including the batch capacity up to 1000. It adds meaning beyond the bare schema, though details on required/non-required are not given.
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?
Description clearly states the tool checks coverage, data staleness, and cost for a US address/point. It distinguishes single vs batch mode and uses 'pre-flight' to indicate it should be called before spending. The specific verbs and resources are clear, and the tool's purpose is distinct from siblings like 'ask_inspector' 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?
Description explicitly says 'Call this before spending' and explains when to use single address vs batch mode. It implies the tool is free. It does not exclude alternatives or provide when-not guidance, but the context of siblings and the pre-flight nature make usage clear enough. A slight gap for not mentioning when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_motion_historyAMulti-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 |
| Name | Required | Description |
|---|---|---|
| dates | No | |
| delta | No | |
| cum_mm | No | |
| status | No | |
| cost_usd | No | |
| credits_remaining_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds cost details ($0.40, free for misses), free preview via dry_run, and free return for stale data via max_age_days. This goes beyond annotations but lacks details on behavior when location parameters are ambiguous.
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?
Three sentences, front-loaded with purpose, each sentence adds distinct value (date range, cost, free preview). No filler or 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?
Covers core functionality, cost, and free options well. However, with 7 parameters (0 required) and low schema coverage, the description leaves ambiguity about location parameter interplay. Output schema exists so return format is not required, but location handling is missing.
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 only 29%. The description adds date format (YYYY-MM-DD) and clarifies dry_run and max_age_days, but does not explain lat/lon/address usage or dependency. With low coverage, more compensation was needed.
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 retrieves multi-year cumulative motion history for an address over a date range. It specifies the resource ('motion history') and action ('get') and distinguishes from sibling tools like check_ground_motion by focusing on cumulative history.
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?
Provides guidance on parameters (from_date, to_date format, dry_run for free preview, max_age_days for stale data) and cost implications. However, it does not explicitly state when to use this tool versus alternatives like check_ground_motion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageAFREE: 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 |
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | No | |
| spent_today_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by noting the tool is FREE and returns line-item details. Annotations already declare readOnlyHint=true, so no contradiction. The description enhances understanding of what the tool does.
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, well-structured sentence that conveys all necessary information without redundancy or 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 and the tool's simplicity (read-only list with one parameter), the description is adequately complete. It mentions the key output fields, providing sufficient context for an AI 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?
The input schema already provides full coverage for the single parameter 'limit', describing default and max. The description does not add additional semantic meaning 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 states the tool returns recent billed calls with specific fields (request_id, endpoint, address, cost). It uses specific verbs and resources, and distinguishes itself from siblings by focusing on usage reconciliation.
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 mentions the use case ('so you can reconcile spend against reports'), providing clear context. However, it does not explicitly exclude scenarios or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_agentAInspectFREE: 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 |
| Name | Required | Description |
|---|---|---|
| api_key | No | |
| password | No | |
| credits_usd | No | |
| reports_remaining | No | |
| price_per_report_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the call is free, creates an account, and returns credentials. Annotations already indicate non-readOnly and non-idempotent. Could add detail on email verification or rate limits, but provides solid context.
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?
Two sentences pack all essential information: free one-step registration, use case, and post-call instructions. No redundant words, front-loaded with key action.
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 output schema and 100% schema coverage, the description covers purpose, usage, and parameter guidance thoroughly. No missing information for a self-registration 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?
Adds significant meaning beyond the schema: specifies that email must be durable (disposable domains rejected) and that password is optional and auto-generated if omitted. This helps the agent select valid inputs.
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 creates a new SibFly account with an API key and free starter credits in one call. The verb 'create' and resource 'account' are explicit, and the context of no human/captcha/card differentiates it from any potential alternative registration flows.
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?
Explicitly says 'Use this when you have no API key' and instructs to save and reuse the api_key. However, it does not explicitly mention when not to use, such as if the user already has an account.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.