删一条我的链接
remove_profile_link登录;按 url(可加 type 进一步限定)删除当前用户的链接。匹配不到则 no-op。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 要删除的链接 url,需与现有完全一致 | |
| type | No | 可选,进一步限定类型 |
remove_profile_link登录;按 url(可加 type 进一步限定)删除当前用户的链接。匹配不到则 no-op。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 要删除的链接 url,需与现有完全一致 | |
| type | No | 可选,进一步限定类型 |
Changes observed during successful MCP inspections.
Input schema / properties / type / descriptionPrevious value: -"可选,进一步限定类型"New value: +"可选,进一步限定类型"Input schema / properties / url / descriptionPrevious value: -"要删除的链接 url,需与现有完全一致"New value: +"要删除的链接 url,需与现有完全一致"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply idempotentHint=true, so the description carries extra weight. It adds two useful facts: authentication is required, and a non-matching url silently does nothing rather than erroring. This explains the idempotency claim. It does not say whether the deletion is reversible or what happens when multiple links share the same url, leaving a small gap.
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?
It is three short semicolon-separated clauses with no filler, and the auth prerequisite comes first. The telegraphic style ('登录;') is efficient, though slightly clipped.
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 two-parameter, fully documented delete tool with no output schema, the description covers the auth prerequisite, the matching key, the optional narrowing parameter, and the no-match behavior. Only the side effects on visibility or on other links remain unstated.
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 parameters are documented there, so the schema does the heavy lifting. The description restates that type optionally narrows the match, which is essentially a paraphrase of the schema text. This is baseline-level added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and scope, deleting a link that belongs to the current user, and names the match key (url). It keeps the resource separate from its sibling add_profile_link because the verb 'delete' is unambiguous. It never names the sibling explicitly, though, so the differentiation is implicit.
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 '登录' (login required) preface and the url-based targeting imply when the tool applies, and '匹配不到则 no-op' clarifies the no-match path. There is no explicit statement about when not to use it, or about the add_profile_link alternative. Usage is therefore implied but not fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.