Read and edit your noiz link-in-bio page: views and clicks, links, name, bio and location.
Scored across 8 tools
Each tool targets a distinct action on a distinct resource: links (add/update/archive/reorder/feature), page profile (update_profile_text), page read (get_my_page), and analytics. No two tools overlap in purpose, so an agent can easily select the right one.
All eight tools follow a consistent snake_case verb_noun pattern (e.g., add_link, get_analytics, update_profile_text). The only minor deviation is the possessive 'my' in get_my_page, but it still fits the pattern.
8 tools is well-scoped for managing a creator's Noiz page. Each tool earns its place by covering a distinct operation, with no redundant or missing count concerns.
Core link lifecycle (add, update, archive, reorder, featured) and profile text updates are covered, plus page read and analytics. However, group management (create/rename/delete/reorder groups) is entirely missing, and update_link cannot change group assignment, schedule, or kind; page address also cannot be updated. These gaps could block agents on common group-related tasks.
Adds a link at the end of the creator's page, or at the end of one of its groups.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A web address, an email address or a phone number | |
| title | Yes | What the button says, up to 100 characters | |
| group_id | No | A group's id from get_my_page, to add it inside that group |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover non-read-only, non-destructive, non-idempotent, open-world. The description adds placement behavior (append at end) and implicitly no return info. With annotations, the bar is lower; the description adds the append-at-end detail, which is 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?
One sentence, front-loaded with verb and resource, and includes the placement scope. 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?
For a simple creation tool with full schema coverage and annotations, the description is adequate but lacks guidance on when to use it vs update_link or how group_id interacts with page placement. Output schema absent, but return values are simple enough.
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%, so parameters are well documented. The description only clarifies that group_id placement is optional by saying 'or at the end of one of its groups'. 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 ('Adds') and resource ('a link') and clarifies placement ('at the end of the creator's page, or at the end of one of its groups'). Distinguishes from update_link/archive_link by implying creation, but doesn't explicitly name siblings.
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 explicit when-to-use vs alternatives; the agent must infer from sibling names. The placement clause gives some context but not a rule for choosing group_id vs page-level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Takes a link off the page by archiving it. Nothing is deleted: the creator can bring it back from the dashboard (https://app.noiz.bio).
| Name | Required | Description | Default |
|---|---|---|---|
| link_id | Yes | A link's id, from get_my_page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds genuinely useful context the annotations cannot convey: the operation is reversible, nothing is deleted, and recovery is available via the dashboard URL. That resolves the natural worry triggered by destructiveHint. It still doesn't say what happens to page ordering or whether the link still occupies a slot.
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 action and immediately followed by the reversibility guarantee plus a concrete recovery URL. No filler, nothing to cut.
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 single-parameter, no-output-schema operation, the description covers the essential behavioral risk (reversibility) and the recovery path. It could be slightly more complete about the effect on page layout/ordering and whether the action is immediate, but nothing critical to correct invocation 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?
There is one parameter with 100% schema description coverage, and the schema itself already tells the agent to source link_id from get_my_page. The description adds no additional meaning about the identifier, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource: 'Takes a link off the page by archiving it' tells the agent exactly what happens, and 'archive' implicitly separates it from siblings like add_link, update_link and reorder_links. It stops short of naming which sibling to use when the user actually wants removal instead of archiving, so it is clear but not sibling-routing.
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 — use this when a link should leave the page but not be destroyed — and the recoverability note hints at when it is safe to call. There is no explicit statement of prerequisites, when NOT to use it, or which sibling (e.g. update_link) to prefer for other intents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Views and link clicks for the creator's page over the last N days, per day, with the ten most clicked links. noiz keeps 90 days of history, so 90 is the most there is.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days back, counting today, up to 90 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior beyond that: a 90-day retention window, per-day granularity, and a top-10 link cap — details that shape what the agent can expect and request.
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, zero filler, and the core payload (views/clicks, per day, top ten links) is front-loaded ahead of the constraint. Every clause 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?
With no output schema present, the description carries the return-shape burden and does so by naming the per-day series and the top-ten link breakdown. Combined with the retention limit and the covering annotations, an agent has everything needed to call this 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% and the single 'days' parameter is already documented with default 30, min 1, max 90. The description adds the rationale behind the ceiling ('noiz keeps 90 days of history'), which explains why 90 is a hard cap rather than an arbitrary one, and restates the day-window semantics.
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 exactly what is returned — per-day views and link clicks for the creator's page plus the ten most clicked links — which is a specific resource with a specific shape, not a restatement of the name. It is trivially distinguishable from every sibling, all of which are write/mutation tools (add_link, archive_link, reorder_links, update_profile_text).
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 read-oriented framing and by the fact that no sibling tool competes for this purpose, but the description never states when to reach for it or any prerequisite. It does supply one operational boundary (90 days of history is the maximum), which an agent can use as a limiting condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The creator's noiz page: its address, display name, bio, location, Premium status, its link groups and every link (id, title, address, kind, visible, featured, group, schedule), and its lifetime views when the creator allowed views and clicks. Archived links are left out.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral detail beyond that: archived links are excluded from the result, and lifetime views are only present when the creator allowed views and clicks. Auth and error behavior are not discussed, keeping it from 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?
A single sentence with the resource front-loaded and no filler; the long parenthetical field list is dense but each item is informative. It is efficient, though the enumeration borders on a raw field dump.
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 no output schema, the description carries the burden of describing the return shape and does so comprehensively, including conditional and excluded fields. It does not address failure modes or the implicit 'my own page' auth context, so it is strong but not exhaustive.
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 takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly avoids inventing parameters.
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 names the specific resource (the creator's noiz page) and enumerates its contents — address, display name, bio, location, Premium status, link groups, links, lifetime views — so an agent knows exactly what it returns. The read verb is only carried by the title, and the description never explicitly contrasts itself with siblings like get_analytics or update_profile_text, 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?
There is no statement of when to use this tool versus alternatives; the sibling set contains get_analytics (metrics) and several link mutations, and none are referenced. Usage can only be inferred from the resource name in the title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Puts the page's links in a new order. Name every link on the page exactly once, top first.
| Name | Required | Description | Default |
|---|---|---|---|
| link_ids | Yes | Every link id, in the new order |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, so the safety profile is covered. The description adds real value beyond that: the top-first ordering direction and the exactly-once completeness requirement, which explains why an incomplete list is dangerous. It still doesn't say what happens if a link is omitted (error vs. removal), which matters given destructiveHint=true.
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 filler, with the operation stated first and the critical constraint immediately after. Nothing here could be cut without losing 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?
For a one-parameter mutation with no output schema and annotations that already carry the safety hints, the description covers purpose, ordering direction, and the completeness rule. The remaining gap — what an omitted link does given destructiveHint=true — is the one thing an agent would still want to know before calling it.
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% and the single parameter is self-describing ('Every link id, in the new order'), so the baseline would be 3. The description adds meaning the schema lacks: 'top first' disambiguates what 'the new order' means (index 0 = topmost) and 'exactly once' flags the uniqueness constraint on the array.
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 ('puts ... in a new order') and resource ('the page's links'), and no sibling tool (add_link, update_link, set_featured_link, archive_link) performs ordering, so it is trivially distinguishable. An agent knows exactly what operation this is 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?
'Name every link on the page exactly once' is an important operational precondition — it tells the agent this is a full-replacement of the ordering, not a partial tweak, which is the main way an agent could misuse it. It does not, however, name when to prefer this over update_link or how archived/hidden links are treated, so no explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Makes one link the page's featured link, or (with link_id null) features none.
| Name | Required | Description | Default |
|---|---|---|---|
| link_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=true, lowering the burden. The description adds genuinely new behavior beyond them: featuring is exclusive (one featured link) and passing null clears the current feature, which is the key state-change an agent must anticipate.
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, front-loaded with the primary effect and the exceptional null case parenthetically. Every clause earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation with no output schema and annotations covering safety and idempotency, the description supplies purpose and the null semantics. Only minor gaps remain, such as which page is affected and whether a prior featured link is replaced silently.
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 0% for the nullable link_id (only the string branch has a short description), but the description explicitly defines the null branch ('features none'), which the schema leaves undocumented. That compensates well for the coverage gap.
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 ('Makes one link the page's featured link') and covers the clearing case, so an agent can distinguish it from update_link or reorder_links. It does not explicitly name those siblings, so it falls just 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?
Usage is only implied: the tool's name and purpose suggest when to call it, and the null case hints at how to unfeature. There is no statement of when to prefer this over update_link, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Changes a link's title or address, or shows or hides it. Leave out what should stay as it is.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | A web address, an email address or a phone number | |
| title | No | What the button says, up to 100 characters | |
| link_id | Yes | A link's id, from get_my_page | |
| visible | No | false hides the link without removing it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the write/overwrite profile is covered structurally. The description adds the genuinely useful partial-update semantics (omitted fields are preserved), but says nothing about reversibility of a URL overwrite or the fact that hiding is recoverable, which is the interesting distinction for a destructiveHint tool.
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, no filler, and the mutation scope is front-loaded before the partial-update rule. Every clause carries 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?
With full schema coverage and four annotations present, the description only needs to add the interaction contract, which it does via the partial-update rule. It stops short of noting that link_id comes from get_my_page or that a hidden link can be re-shown, but nothing essential to a correct call 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 link_id, url, title, and visible are all documented in the schema, including the 'false hides the link without removing it' semantics. The description's mention of title/address/visibility merely mirrors the schema without adding format or constraint detail beyond it, 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?
The description names a specific verb (Changes) plus resource (a link) and enumerates exactly which attributes are mutable: title, address (url), and visibility. The 'shows or hides it' clause implicitly distinguishes it from archive_link (permanent removal) and add_link (creation), so an agent can route correctly 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?
'Leave out what should stay as it is' gives a useful partial-update contract, which is real usage guidance. However, it never states when to prefer this tool over archive_link for removing a link, nor when visible=false is preferable to archiving, so the alternative-selection guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Changes the page's display name (up to 100 characters), bio (up to 500) or location (up to 80). Leave out what should stay; an empty string clears it.
| Name | Required | Description | Default |
|---|---|---|---|
| bio | No | ||
| location | No | ||
| display_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true but say nothing about mechanism. The description adds the crucial nuance that an empty string clears a field, which is exactly the behavior an agent needs to avoid accidental data loss, plus the fact that omitted fields are preserved.
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 tight sentences with no filler. The field list comes first and the critical partial-update rule is front-loaded in the second sentence.
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 mutation tool with no output schema, the description covers purpose, field semantics, and the destructive edge case. Remaining gaps (e.g., what the response contains, whether simultaneous multi-field updates are allowed) are minor given annotations carry the safety profile.
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 0%, so the description carries the load: it maps the three parameters to their meaning and, more importantly, explains the omit-to-keep / empty-string-to-clear semantics that the schema does not encode at all. Length limits are repeated from the schema but the semantic layer is genuinely additive.
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 names a specific verb (changes) and the exact resource fields (display name, bio, location), making it unambiguous against siblings like update_link or add_link. It also scopes each field with a length limit, reinforcing what the tool operates on.
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?
There is no explicit when-to-use vs. alternative guidance and no sibling tool is named. Usage is only implied, though the partial-update rule (omit to keep, empty string to clear) does tell the agent how to invoke it correctly.
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.
add_linkarchive_linkget_analyticsget_my_pagereorder_linksset_featured_linkupdate_linkupdate_profile_textManage your Snapto link-in-bio page: links, social icons, and visit and click analytics.
Make and edit a hand-made link-in-bio page: add links, pick a look, publish.
Manage BioFlow link-in-bio pages, blocks, leads, and analytics from AI agents.
Manage your details.page link-in-bio from Claude: edit details, post updates, read analytics.
Add one secure layer between your agents and this server.
