A Snapchat public profile: name, bio, subscribers, category. (1 credit)
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"handle": "<handle>"
},
"name": "snapchat_profile"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Snapchat username. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context in the credit cost (1 credit) and the shape of the returned data, but says nothing about failure modes such as nonexistent, private, or suspended handles.
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 front-loaded sentence listing the resource and its fields, plus a parenthetical cost note. Nothing is padded, though the field list is the only substantive content and the sentence could have been used to convey usage instead.
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, listing the returned fields is a helpful substitute and the credit cost is disclosed. However, for a single-parameter public-data lookup the description omits handle formatting rules and error behavior, leaving a few practical gaps.
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 a single required parameter with 100% schema description coverage ('Snapchat username'), so the schema carries the burden. The description adds no format guidance (e.g., with or without leading '@', case sensitivity), which is the one piece of meaning it could have contributed.
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 resource (Snapchat public profile) and enumerates the fields returned (name, bio, subscribers, category), so an agent knows exactly what it retrieves. It is a noun phrase rather than a verb, but the read intent is unambiguous, and it is clearly distinct from the many profile tools for other platforms in the sibling list.
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 guidance, no prerequisites, and no mention of alternatives or follow-up tools. The agent must infer usage from the name alone; nothing states that this is the entry point for a Snapchat handle versus other platform profile tools.
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.