Create file upload links, publish Markdown pages and receive webhooks, then query incoming files and requests. A hosted streamable HTTP MCP server for AI agents, with no authentication needed for anonymous links that last 24 hours.
Scored across 7 tools
The three creation tools (create_upload_link, create_webhook, share_page) all produce a 'link' but target clearly different use cases, and list_files vs read_webhook_requests are tied to distinct link types. The only mild blur is that delete_link and get_link_stats are generic over all link types, but descriptions make intent clear enough.
All seven tools use consistent snake_case verb_noun form (create_upload_link, create_webhook, delete_link, get_link_stats, list_files, read_webhook_requests, share_page). No mixing of conventions or vague verbs.
Seven tools is well-scoped for a link-sharing service: three creation tools, one delete, one stats, and two read-back tools. Each earns its place with no redundancy.
The lifecycle is largely covered: create (three link types), delete, stats, and read files/webhook requests. The notable gap is no way to enumerate or list existing links, and no per-file deletion, though agents can work around these by tracking ids/keys.
Make a web page where a person can send you files (no account needed on their side). Use it when you need a file from someone outside this chat: a signed document, a photo, an export. Give them the url; keep id and key to fetch the files with list_files. Expires in 24 hours unless the user connected a hello.new account.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Shown on the upload page, e.g. "Please upload the signed lease". | |
| max_files | No | How many files the page takes. Default 10. | |
| expires_in | No | Seconds until the link expires. Default: 24 hours, or never on a hello.new account. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| key | Yes | For the other tools. Never give it out. |
| url | Yes | The link. Give it to people. |
| claim_url | No | Anonymous links: where the user can keep the link past 24 hours. |
| stats_url | Yes | A live dashboard of who opened the link, for the user. |
| expires_at | Yes | null: it never expires. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that recipients need no account, that the link expires in 24 hours unless a hello.new account is connected, and that the caller must retain id and key to fetch files later — all operationally important context the annotations do not convey.
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 tightly packed sentences, front-loaded with the core capability and followed by usage, credential handling, and expiry — no filler.
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, return values need not be explained; the description covers the recipient's no-account flow, the credential handoff to list_files, and the expiry rule, leaving no critical gap for calling the tool 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 description coverage is 100%, so note, max_files, and expires_in are already fully documented with defaults and bounds. The description's expiry sentence adds only marginal reinforcement rather than new parameter meaning.
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?
States a concrete verb and resource ('make a web page where a person can send you files') and clarifies the direction of transfer, which distinguishes it from sibling tools like share_page.
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?
Gives a clear triggering condition and concrete examples ('a signed document, a photo, an export'), and routes the agent to list_files for retrieval. It lacks an explicit when-not or negative case, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a URL any service can call: Stripe, GitHub, a form, a cron job. Every request is stored for you to read with read_webhook_requests. Expires in 24 hours unless the user connected a hello.new account.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | What the webhook is for, e.g. "Stripe test events". | |
| expires_in | No | Seconds until the link expires. Default: 24 hours, or never on a hello.new account. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| key | Yes | For the other tools. Never give it out. |
| url | Yes | The link. Give it to people. |
| claim_url | No | Anonymous links: where the user can keep the link past 24 hours. |
| stats_url | Yes | A live dashboard of who opened the link, for the user. |
| expires_at | Yes | null: it never expires. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false). The description adds real behavioral value beyond them: request persistence ("Every request is stored") and the 24-hour expiry with its hello.new exception. It does not mention auth or rate-limit behavior, keeping it short of a 5.
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 short sentences, zero filler. The core capability is front-loaded, followed by the reading path and the expiry caveat in priority order.
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, return values need no explanation, and the description covers the essentials an agent needs: what the tool produces, where the output surfaces (read_webhook_requests), and the lifetime constraint. Nothing material 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 100%, so both parameters are already documented in the schema, including the expiry default and the note field. The description's expiry statement merely echoes the schema, adding no new syntax or constraint detail. Baseline 3 applies.
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?
States a concrete verb+resource ("Make a URL") and clarifies the mechanism with examples ("Stripe, GitHub, a form, a cron job"). It is clearly distinguishable from create_upload_link by describing an inbound-callable endpoint, though it never names that sibling 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?
Gives strong usage context: the URL is meant to be called by external services, and requests are consumed via read_webhook_requests, which routes the agent to the right companion tool. It stops short of stating when NOT to use this versus create_upload_link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one of your links and everything in it right away. Anyone who opens it afterwards gets a 404.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The link id, from the tool that made the link. | |
| key | Yes | The link's key, from the tool that made the link. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| deleted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, so the safety profile is covered. The description earns credit by adding concrete consequences beyond the annotations: deletion is immediate ('right away') and public-facing ('anyone who opens it afterwards gets a 404'). It still omits reversibility/auth requirements, but the consequence disclosure is genuinely useful.
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 short sentences, zero waste, with the destructive scope front-loaded before the post-condition. Ideal sizing for a simple two-parameter tool.
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?
An output schema exists, so return values need not be explained, and the description covers scope and the external consequence of deletion. The remaining gap is whether the action is recoverable or requires confirmation, which matters for an irreversible operation.
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% and both required parameters (id, key) are documented in the schema as coming 'from the tool that made the link.' The description adds nothing about parameter meaning, so the baseline 3 applies.
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?
States a specific verb (Delete) and resource (link) with scope: 'everything in it' is removed. It doesn't explicitly contrast with siblings, but the sibling set (create_upload_link, get_link_stats, etc.) is functionally distant enough that disambiguation isn't needed.
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 when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer that this is the terminal removal action; nothing tells it when deletion is appropriate versus other link-management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See who opened one of your links: views, visitors, countries, devices, referrers and agent reads. Also returns stats_url, a live dashboard the user can open.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The link id, from the tool that made the link. | |
| key | Yes | The link's key, from the tool that made the link. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| full | Yes | |
| kind | Yes | |
| locked | No | Anonymous links: what keeping the link unlocks. |
| totals | Yes | |
| claim_url | No | |
| countries | No | |
| stats_url | Yes | The same as a live dashboard, for the user. |
| expires_at | No | null: it never expires. |
| timeseries | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral value by disclosing the return contents, including the metrics and the stats_url live dashboard the user can open, which the annotations cannot convey.
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 short sentences, front-loaded with the core purpose followed by the return-value highlight; the stats_url mention is a concrete, useful addition. 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?
An output schema exists, so return values need not be explained, yet the description helpfully summarizes them. All required-parameter provenance is covered, leaving little missing for a read-only stats tool; only the absence of any pagination/time-window guidance holds it back from 5.
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 both required parameters (id, key) are already documented in the schema, including their provenance. The description adds no additional parameter meaning, format, or constraints, so baseline 3 applies.
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?
States a specific verb and resource ('See who opened one of your links') and enumerates the exact metrics returned (views, visitors, countries, devices, referrers, agent reads). This scope clearly separates it from siblings like create_upload_link, delete_link, and list_files, so an agent can identify it without opening the schema.
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?
Usage is implied by the purpose, and the description hints the id/key come 'from the tool that made the link,' but it never states when to call this versus alternatives, nor any prerequisites or preconditions. Adequate-but-minimal routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the files people sent to one of your upload links. Small text files come back inline; other files have a download_url to give the user. Set wait (up to 20 seconds) to wait for the first file to arrive.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The link id, from the tool that made the link. | |
| key | Yes | The link's key, from the tool that made the link. | |
| wait | No | Seconds to wait for the first file. Default 0. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| files | Yes | |
| expires_at | Yes | null: it never expires. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/no-destructive safety, so the bar is lower; the description adds genuinely useful behavior by disclosing that small text files return inline while others carry a download_url, and that wait up to 20s long-polls for the first file. That is real operation-level 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?
Three tight sentences with the action front-loaded, followed by return-shape behavior and the optional wait semantics. Every sentence earns its place with no filler.
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?
An output schema exists, so return structure need not be spelled out, yet the description still usefully previews inline vs download_url handling. Combined with complete parameter coverage and clear safety annotations, nothing an agent needs to invoke it correctly 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 100%, so all three parameters are documented in the schema itself; the baseline is 3. The description restates the wait semantics ('wait for the first file to arrive') but adds no syntax or defaults beyond what the schema already says.
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?
States a specific verb+resource ('List the files people sent to one of your upload links'), which is unambiguous and separable from siblings like get_link_stats or create_upload_link. It does not explicitly name a sibling to contrast against, so it falls just short of 5.
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?
Usage is implied: it operates on an existing upload link whose id/key come from 'the tool that made the link', and the wait parameter implies a polling/waiting scenario. But there is no explicit when-to-use or when-not-to-use guidance against alternatives such as get_link_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the requests your webhook URL received: method, headers, query and body. Pass after (the last seq you saw) to get only newer ones, and wait (up to 20 seconds) to wait for the next request.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The link id, from the tool that made the link. | |
| key | Yes | The link's key, from the tool that made the link. | |
| wait | No | Seconds to wait for the next request. Default 0. | |
| after | No | The last seq you saw: only newer requests come back. Default 0. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| requests | Yes | |
| expires_at | Yes | null: it never expires. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it reveals the returned request parts, incremental polling via 'after', and a blocking wait of up to 20 seconds.
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 tightly written sentences with zero waste. The first sentence front-loads purpose and return contents; the second efficiently explains the two optional parameters. The minor 'wait ... to wait' repetition does not undermine the conciseness.
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 read tool with 4 parameters, 2 required, full schema coverage, and an output schema, the description supplies all needed invocation context. Safety is covered by annotations, return shape by the output schema, and polling behavior by the description.
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 the schema already documents every parameter, including 'after' and 'wait'. The description reinforces these semantics (newer requests, up to 20 seconds) but adds no format details, edge cases, or defaults beyond what the schema provides; baseline 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?
States a specific verb 'read' and resource 'requests your webhook URL received', and enumerates the returned fields (method, headers, query, body). It does not explicitly differentiate itself from sibling tools like get_link_stats or list_files, so it falls short of a 5.
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 by explaining incremental retrieval with 'after' and long-polling with 'wait', but it never explicitly states when to use this tool versus any alternative. Sibling tools are unrelated operations, so no clear alternative selection guidance is provided or needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_upload_linkcreate_webhookdelete_linkget_link_statslist_filesread_webhook_requestsshare_page
Add one secure layer between your agents and this server.