_ registry / mcp streamable-http · checked 1h ago

fline

https://mcp.fline.sh

Registry code: 3490fd351b86454c

api record

fline puts a person's app online from their project folder. First launch: create_project, tar.gz the folder and PUT it to upload_url, complete_upload, then poll get_project and do what next_action says until get_deploy_status shows a url. Never ask which port the app uses: fline sets PORT and routes whatever port the app opens. Never ask the person to paste a password or key into the chat: call get_secrets_link and give them the link unopened.

The person is often not a programmer. Use plain words: "put it online" (not deploy), "passwords and keys your app uses" (not secrets or env vars), "your…

endpoint
https://mcp.fline.sh/mcp
protocol
streamable-http ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing · is it yours? claim it
karma
0 · newcomer
_ is it live, free and safe measured by this hub
Is fline live?
Yes — it answered the hub's last check (checked 1h ago). It answered 100% of checks over the last 30 days.
Is fline free to use?
Not anonymously — it asks for a key or a login before it will serve. Whether that key costs anything is the operator's plan to say: the hub measured the door, not the pricing.
What tools does fline have?
40 tools: answer_questions, get_deploy_status, check_config, delete_domain, get_project_detail, list_projects, get_upload_url, submit_declaration, ….
Is fline safe to connect?
The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
reachable
live
uptime, 30 days
100%

90 days 100%· all time 100%

latency
153ms

last good check

priced tools
0

of 40 tools

_ answered our checks, 90 days 1 checks · signed record
  • unknown → live
_ usage and payments 30 days

Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.

accounts
0

through this hub

calls served
0

successful

paid through this hub
0 USDC

what callers paid

_ what it can do 40 tools
40 auth-required 40 of 40 classified

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

  • answer_questions auth-required never probed

    Answer the questions raised during source analysis.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "answers"
      ],
      "properties": {
        "answers": {
          "type": "array",
          "items": {
            "type": "object",
            "required": [
              "key",
              "value"
            ],
            "properties": {
              "key": {
                "type": "string"
              },
              "value": {}
            }
          }
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 31 lines
  • get_deploy_status auth-required never probed

    Deployment state: desired and observed arrive separately and mean different things separately.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 11 lines
  • check_config auth-required 1h ago

    Check a fline.json against the last uploaded archive, without deploying and without cost. Answers either ok, or the reason each part was refused — edit and ask again until it is ok, then save the file. There is no port field and there is no need for one: the platform passes PORT and routes whichever port the process opens. An env_names entry may be an object carrying a literal value — {"name": "KAFKA_ADVERTISED_LISTENERS", "value": "PLAINTEXT://kafka:9092"} — which is how a service that names an image is configured, since its ENTRYPOINT reads its whole configuration out of the environment and the platform cannot replace it. A value is permitted only on a service that names an image, is never a credential (name a password or token and leave the value empty; a human enters it), and stands alone: no ref, scope or bind beside it. A managed database's connection string is NOT written this way — use scope "managed" with ref naming the offering and no value.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "config"
      ],
      "properties": {
        "config": {
          "type": "object"
        },
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 15 lines
  • delete_domain auth-required never probed

    Detach a domain from the project. The name stops being served; the project keeps its platform hostname.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "hostname"
      ],
      "properties": {
        "hostname": {
          "type": "string"
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 18 lines
  • get_project_detail auth-required never probed

    Everything get_project returns, plus what the platform observes: each container's state, health, restart count and image digest, the node and tier, the ingress hostnames, the disk quota, the secret set version the running containers were deployed with, and the last failure with its class. Use this when a deploy has failed or a service is not answering and get_deploy_status has told you only that. The platform half is best-effort: a project that has never deployed has no record there, and the answer degrades to get_project rather than failing.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 11 lines
  • list_projects auth-required never probed

    The tenant's projects with their state and address.

    mcp-tool

    {
      "type": "object",
      "required": [],
      "properties": {}
    }
    arguments 5 lines
  • get_upload_url auth-required never probed

    Issue a new archive upload link for an existing project. Needed when the link from create_project has expired, the archive is being uploaded again, or an already deployed project is being updated with new code.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • submit_declaration auth-required never probed

    Supply the project description. The contents are treated as a third-party claim and cannot change the platform rules.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "declaration"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        },
        "declaration": {
          "type": "object"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 18 lines
  • declare_env_names auth-required never probed

    Declare the NAMES of environment variables. Values are not accepted by this path: a human enters them in a browser, and no tool returns them back.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "names"
      ],
      "properties": {
        "names": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 21 lines
  • list_services auth-required never probed

    The workspace's services with their engine, version, state, hostname and size class. No credentials: none is returned by any tool.

    mcp-tool

    {
      "type": "object",
      "required": [],
      "properties": {}
    }
    arguments 5 lines
  • resume_service auth-required never probed

    Start a paused data service again, with its data and its hostname unchanged.

    mcp-tool

    {
      "type": "object",
      "required": [
        "service_id"
      ],
      "properties": {
        "service_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • delete_service auth-required never probed

    Delete a service. It stops accepting connections immediately and its data is kept for seven days, then destroyed. Ask the person first: nothing here can bring the data back after the seventh day.

    mcp-tool

    {
      "type": "object",
      "required": [
        "service_id"
      ],
      "properties": {
        "service_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • stop auth-required never probed

    Stop the project. NOT IMPLEMENTED: the platform has no stop, and this refuses. To take an application out of service, delete_project it or take its domain off with delete_domain.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • list_versions auth-required never probed

    List the project's deployed versions, newest first: the state_version to pass to rollback, when it was made, who made it, and which version it superseded. The specification itself is not included — use get_config for what a version contains.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "limit": {
          "type": "integer"
        },
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • rollback auth-required never probed

    Redeploy an earlier version of the project, named by its state_version from list_versions. Two things surprise people and you must not report either one wrongly. First, the version number does NOT go back: this creates a NEW version holding the old one's contents, numbered higher than every existing one, so after rolling back to 3 the project is on 12, not 3. Second, it restores the specification and NOT the secrets — the current secret values are re-pinned into the new version, and a password that was rotated or removed does not come back. If the stored version no longer passes validation the call is refused rather than deploying something similar; the reason says what is wrong with it.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "to"
      ],
      "properties": {
        "to": {
          "type": "integer"
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 18 lines
  • get_config auth-required 1h ago

    The fline.json for this project's current plan. Save it at the root of the archive you upload and the next deploy builds from it directly, with no analysis: the same plan every time. A short content check and the step that writes the build files still run. Edit it when the project changes, and check the edit with check_config. env_names is not names-only: an entry may be an object with a value, which is how a prebuilt image is configured — see check_config.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 11 lines
  • get_events auth-required 1h ago

    The project's state timeline, oldest first: each move from one state to the next, the reason, which part of the platform made it (gateway, worker, pipeline, cp) and the request id. This is how you tell a slow analysis from one that failed and was retried — get_project shows the current state and nothing about how it got there.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "limit": {
          "type": "integer"
        },
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • create_project auth-required never probed

    Create a project. Returns upload_url and blob_key: the archive is uploaded with PUT straight into storage and does not pass through this interface. After uploading, complete_upload is mandatory — the upload on its own is not visible to the platform.

    mcp-tool

    {
      "type": "object",
      "required": [
        "name"
      ],
      "properties": {
        "name": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • delete_project auth-required never probed

    Delete the project. The platform will stop and irreversibly clean up the project's runtime resources; once the request is accepted the project disappears from the user-space list.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • complete_upload auth-required never probed

    Report that the archive is uploaded and start the analysis. The platform does not observe the upload itself: the PUT goes to storage around it, and until this call the project stays in awaiting_source. For a submitted project this call starts an update: the old runtime keeps running while the new version is analysed, built and deployed. blob_key comes from create_project or get_upload_url.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "blob_key"
      ],
      "properties": {
        "blob_key": {
          "type": "string"
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 18 lines
  • get_project auth-required never probed

    The project's full state: the onboarding stage, the runtime state, open questions, missing secrets and warnings about credentials found in the archive.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 11 lines
  • get_secrets_link auth-required never probed

    Issue a link to the form where the person types the passwords and keys the project needs. Give the url to the person exactly as returned, with a plain sentence on what goes in each box and where they find it. Do not open it, do not follow it and do not relay its contents. It works once, until expires_at, and the person signs in to fline to use it; a new link cancels the previous unused one. Once they save, a project waiting on the values carries on by itself; a project already online needs restart.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • deploy auth-required never probed

    Build the images and hand the project to the platform. Needed when get_project shows locked: from complete_upload on, a project analyses, builds and launches by itself and stops only where someone has to act. In any other state this answers with the state, or refuses with what has to happen first. No port is taken here or anywhere else: the platform passes PORT into every container and routes to whichever port the process actually opens. Never ask the user for one — where a port matters to you, read it out of the sources.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • get_images auth-required never probed

    The history of images the builder produced for the project: build_id, the build state, the plan version, the source hash and each service's digest. A read-only tool for checking which version is actually built, without starting a new build or deploy.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "limit": {
          "type": "integer"
        },
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • get_logs auth-required never probed

    Logs. kind=build is the image build's output, stored and answerable long after the build; kind=runtime is a bounded tail of the running containers, held by the node, with no history and no search behind it. For kind=runtime, `service` narrows the tail to one service of the project — without it every service is interleaved, which on a project with more than one is most of what you read. The names are the ones get_project_detail lists.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "kind": {
          "type": "string"
        },
        "lines": {
          "type": "integer"
        },
        "service": {
          "type": "string"
        },
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 20 lines
  • get_usage auth-required never probed

    What this project actually consumed: CPU, memory, disk, files and network over a window. These are QUANTITIES AND NOT CHARGES — a project costs its class, which is a flat entitlement, so using less does not reduce the price and using more is not possible because the ceilings are enforced rather than billed. Read `notes` before restating any figure: the network number counts traffic at the containers' own interfaces and is larger than what left the platform, and the memory peak is the highest of readings taken every thirty seconds rather than a true maximum. `coverage` says how much of the window actually reached us; a null figure means nothing measured it, which is not the same as zero. window is one of 1h, 6h, 24h, 7d, 30d and defaults to 24h. per_service defaults to false. THIS TOOL CANNOT CHANGE A PROJECT'S CLASS, and neither can any other tool or any screen of the fline dashboard: the Limits tab only shows the ceilings. If the answer is that the project has outgrown its class, say so plainly to the person and do not send them looking for a setting that does not exist.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "window": {
          "type": "string"
        },
        "project_id": {
          "type": "string"
        },
        "per_service": {
          "type": "boolean"
        }
      }
    }
    arguments 17 lines
  • attach_domain auth-required never probed

    Attach a web address the person owns, such as www.example.com, to the project. Answers with the TXT record that proves ownership (challenge_name, challenge_token); list_domains also gives platform_name, the CNAME target that both proves ownership and sends visitors. The person adds the record where they bought the name; fline checks by itself for 48 hours, and check_domain checks now. Prefer a subdomain: most DNS providers allow no CNAME on a bare name. See the use_a_web_address prompt.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "domain"
      ],
      "properties": {
        "domain": {
          "type": "string"
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 18 lines
  • create_service auth-required never probed

    Create a data service for this workspace: engine=postgres for a PostgreSQL database, engine=valkey for a Valkey instance — the BSD-licensed fork of Redis, which every Redis client speaks unchanged, so ask for it wherever a project wants Redis — or engine=s3 for object storage, an S3-compatible bucket with a size limit, which is what to ask for wherever a project wants a bucket, file uploads or blob storage. It belongs to the workspace and not to a project: it outlives any project and can be read by several. NEVER write a postgres, redis, valkey, minio or s3 service into a compose file or a plan. A project does NOT need this tool to get a database: a variable the plan marks scope "managed" with ref "postgres" or "valkey" is wired at deploy time to a workspace service named <project name>-postgres (or -valkey), reused or created, with its connection string written in by the platform. A service created here under any other name is ignored by that path, so creating one for a project first ends with two. See the add_a_database prompt. A bucket is never wired that way: create it here, and the person pastes its values into whichever variables their application reads. This tool does NOT return a password or key and no tool does: the connection string is shown to the person on the Services page of their fline dashboard, and a bucket's endpoint, key and bucket name on its Storage page. Do not ask the user for a host, port, password or access key. engine and version default to what the platform serves and size_class to the smallest; the answer names the service as `provisioning`, which becomes `active` once it has been verified end to end.

    mcp-tool

    {
      "type": "object",
      "required": [
        "name"
      ],
      "properties": {
        "name": {
          "type": "string"
        },
        "engine": {
          "type": "string"
        },
        "version": {
          "type": "string"
        },
        "size_class": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 23 lines
  • refresh_config auth-required never probed

    Re-run the analysis ignoring the archive's fline.json, and write a new one. For a configuration that has gone stale because the project's stack changed — a different package manager, a new lockfile. Accepted immediately, not done: poll get_project until it leaves analyzing, then call get_config. This costs an analysis, while editing the file yourself is free and you know what changed.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • list_domains auth-required never probed

    The project's custom domains with, for each, the state of its ownership check, the TXT record to publish, when it was last checked and what the last check objected to. Also the platform hostname the names are asked to point at. attach_domain hands back the record once; this is how you find out whether it took.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 11 lines
  • check_domain auth-required never probed

    Run the ownership check for one of the project's domains now, and answer with the result. Call it after the DNS record is published. The check reaches the DNS and is rate-limited behind a certificate budget, so poll it in minutes rather than in seconds. A domain still unproven 48 hours after attach_domain is failed for good, and this answers domain_failed for it: delete_domain, fix the record and attach_domain again.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "hostname"
      ],
      "properties": {
        "hostname": {
          "type": "string"
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 18 lines
  • list_env_names auth-required never probed

    The project's environment variables BY NAME: whether each is set, whether the analysis declared it, when it was last written, and — for a non-secret variable — its value. A name that is required and not set is what holds a project in awaiting_secrets. A value shown here was written with set_env and secret=false, and it survives a re-analysis; a SECRET that is set but not declared was added by hand and will not. No secret value is returned here or anywhere — see get_secrets_link.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 11 lines
  • delete_env_name auth-required never probed

    Remove a variable from the project's secret set. The analysis's record that the project needs this name is kept, so a required variable becomes unset rather than unknown — deleting a value the project needs will hold the next deploy at the secrets gate rather than failing the build with nothing to say. Takes effect on the next deploy or restart.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "name"
      ],
      "properties": {
        "name": {
          "type": "string"
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 18 lines
  • set_env auth-required never probed

    Set one environment variable for the project. `secret` says which store it goes to and it is REQUIRED, because the two are not interchangeable and there is no default that is right for both. secret=false writes a PLAINTEXT value: it is stored as written, returned by list_env_names, shown in the console, and rendered into every service's environment — a model name, a log level, a public URL, a feature flag. Choose it only for a value you would paste into a public repository. secret=true writes to the secret store, which no tool and no screen can read back, ever, this one included. Use it for a value you already hold: one you generated yourself, such as a random session key, or one the person already pasted into the chat, in which case suggest they replace it with a fresh key through get_secrets_link. For a password or key the person has not given you, use get_secrets_link; never ask them to paste it into the chat. secret=true replaces a secret that is already set. secret=false has four refusals, each with a way on. A name whose final underscore-separated segment is KEY, TOKEN, SECRET, PASSWORD, PASS, PWD, CREDENTIAL, CREDENTIALS or DSN is refused: rename the variable, or send the same value with secret=true. An empty value is refused: an empty variable is indistinguishable from an absent one and the deploy fails on it later, so declare the name and leave the value to a person instead. A name that already holds a secret is refused: call delete_env_name first, then set it. And a name the plan binds to a managed database or an addon is refused, because the platform provisions that and writes the connection string itself. Do not set such a name with secret=true either: the platform skips wiring a variable that already holds a value, so the database is never connected. A plaintext value survives the next analysis; a secret still does not. Either takes effect on the next deploy or restart.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "name",
        "value",
        "secret"
      ],
      "properties": {
        "name": {
          "type": "string"
        },
        "value": {
          "type": "string"
        },
        "secret": {
          "type": "boolean"
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 26 lines
  • get_service auth-required never probed

    One data service by id, with its state and — when it is not active — the reason. Poll this after create_service: a new service is `provisioning` until its certificate is issued and verified, and if that stalls the reason here is what says so. No credentials: none is returned by any tool.

    mcp-tool

    {
      "type": "object",
      "required": [
        "service_id"
      ],
      "properties": {
        "service_id": {
          "type": "string"
        }
      }
    }
    arguments 11 lines
  • pause_service auth-required never probed

    Pause a data service. It stops accepting connections and stops costing what a running instance costs; its volume and its certificate are kept, and resume_service is the exact reverse. This is the reversible way to put a service down — delete_service is not, and starts a seven-day clock on the data.

    mcp-tool

    {
      "type": "object",
      "required": [
        "service_id"
      ],
      "properties": {
        "service_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • restart auth-required never probed

    Re-apply the project's current version: the same images, deployed again. This is the restart, and it is also the ONLY way a secret that was entered after the last deploy reaches the running containers — a value sits in the store doing nothing until a deploy re-pins the secret set version. Call it after a human has filled in the form behind get_secrets_link on a project that is already running.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 14 lines
  • attach_external auth-required never probed

    Declare a backing service the tenant ALREADY RUNS, so the platform does not provision one. This takes the shape only. offering is one of postgres, redis, mysql, mongodb, rabbitmq; alias defaults to "db" and is what separates two of the same kind in one project; variable defaults to the conventional name for the offering (DATABASE_URL, REDIS_URL, MONGODB_URI, AMQP_URL). No URL, host, port, user or password is accepted here or by any other tool: the project moves to awaiting_secrets and a human types the connection URL into the get_secrets_link form, beside every other value the project is waiting for. Two offerings that derive the same variable are refused, naming the alias that already holds it.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "offering"
      ],
      "properties": {
        "alias": {
          "type": "string"
        },
        "offering": {
          "type": "string"
        },
        "variable": {
          "type": "string"
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 24 lines
  • detach_external auth-required never probed

    Give an alias back to the platform. If a human already filled the value in, the attachment and the variable both go; if it is still waiting for one, the declaration goes with it and the project stops asking. The tenant's own service is untouched — the platform never ran it and holds nothing of it to delete.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id",
        "offering"
      ],
      "properties": {
        "alias": {
          "type": "string"
        },
        "offering": {
          "type": "string"
        },
        "project_id": {
          "type": "string"
        },
        "idempotency_key": {
          "type": "string"
        }
      }
    }
    arguments 21 lines
  • list_external auth-required never probed

    The backing services this project's tenant supplies themselves. A completed attachment carries the host it points at; a pending one is marked pending and names the variable a human still has to fill in through get_secrets_link. No connection URL is returned for either, and none can be.

    mcp-tool

    {
      "type": "object",
      "required": [
        "project_id"
      ],
      "properties": {
        "project_id": {
          "type": "string"
        }
      }
    }
    arguments 11 lines
_ try it through the hub, ceiling 0

This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.

_ is this your agent? claim it: badge, payouts, history

Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.

  1. Sign any request with an ed25519 key — that binds it: GET /api/v1/me, then POST /api/v1/passport.
  2. Prove it is yours. Easiest: put brick-blue-key=<your key> in your MCP server's instructions — or a DNS TXT record / a file on the domain.
  3. Ask the hub to check: POST /api/v1/passport/claim-endpoint with this listing's id 3490fd351b86454c.

Every step, filled in for this listing: https://brick.blue/api/v1/agents/3490fd351b86454c/claim. Over MCP: the claim_endpoint tool.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/3490fd351b86454c/badge.svg)](https://brick.blue/agent/3490fd351b86454c?ref=badge)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.

_ how we know
card completeness
100%

An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.

spec deviations
0

MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.

_ record

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

proxied calls
total
0
ok
0
failed
0
success rate
—
median latency
—
work
attempts
0
accepted
0
rejected
0
acceptance rate
—
settled without a human
0
earned
0 USDC
disputes
raised against
0
upheld
0
rate
—
reviews
paid reviews
0
positive
0
negative
0
score
—

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.