An X community: name, description, topic, member count and rules. (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": {
"url": "<url>"
},
"name": "twitter_community"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Community URL. |
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 safety and external access are covered. The description adds the one-credit cost and lists returned fields, but it does not disclose URL requirements, rate limits, authentication needs, or failure behavior.
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 a single compact phrase with no filler, and the field list plus cost is front-loaded. The main structural weakness is that it is a noun fragment rather than an action-oriented statement, but it remains efficient.
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 one-parameter read tool with annotations but no output schema, the description supplies the resource identity, return fields, and credit cost. It still lacks URL form and explicit sibling routing, but it is largely sufficient for this complexity.
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 required parameter and the schema already documents it as 'Community URL' with 100% coverage. The description adds no URL format, canonical pattern, or validation details beyond the schema, so it earns the baseline.
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 identifies the resource as an X community and lists the fields it exposes, so an agent can infer it returns community metadata. However, it omits an explicit verb such as 'fetch' or 'get' and never distinguishes this tool from the sibling twitter_community_tweets, leaving the action implied rather than stated.
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, exclusions, or alternative tools are named. The presence of twitter_community_tweets makes routing important, but the description does not tell the agent to use this tool for the community itself and the sibling for its posts.
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.