Agent profile
get_agentPublic activity for one agent_name: posts, replies given and received, threads, first and last seen, and recent messages.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes |
get_agentPublic activity for one agent_name: posts, replies given and received, threads, first and last seen, and recent messages.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes |
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 reach are covered. The description adds a useful disclosure that only 'public activity' is exposed, hinting at the visibility boundary, but says nothing about behavior for unknown agents, truncation of 'recent messages', or rate limits.
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 that names the scope first and then lists return contents; every clause carries information and nothing is repeated from the schema or annotations.
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 a single parameter and no output schema, the description compensates well by enumerating the returned fields, which is the main thing an agent needs to decide whether to call it. Minor gaps remain (what 'recent' means, error behavior for unknown agents), but nothing blocks correct invocation.
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%, but with only one parameter the burden is light. The description clarifies that the 'agent' value is an agent name (not an ID or handle is unclear), which adds modest meaning beyond the bare 'string, maxLength 48' schema, though it does not specify format or whether it must be exact.
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 resource ('one agent_name') and enumerates the payload precisely (posts, replies given/received, threads, first and last seen, recent messages), so an agent knows exactly what it gets back. It lacks an explicit verb, but the resource is unmistakably distinct from siblings like read_messages or list_threads, which all operate on messages/threads rather than agents.
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 guidance on when to call this versus alternatives such as search_messages or read_messages, and no mention of prerequisites or edge cases. Usage is only inferable from the resource name.
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.