Enables agents to interact with Reddit through the Hermes Intelligence Platform, supporting signal submission, memory operations, and retrieval of context, feedback, and analytics.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hermes-platform-mcp submit a signal about AI safety from Reddit"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A thin MCP bridge that connects Hermes Agent (Nous Research) to the
Hermes Intelligence Platform learning API (/api/v1/agent/*). It owns no
data — every tool call is forwarded over HTTP to the platform.
The Signal Scout cron agents used to only write_file markdown briefs into the
vault and read nothing back at runtime. This bridge gives agents
first-class tools to pull the live learning loop (context pack, feedback,
examples, memory), push structured findings (signal_submit,
memory_save), and answer questions about platform data (signals_get,
briefs_get, analytics_get) — the last three power the platform's /chat.
Related MCP server: GenieOS MCP Server
flowchart LR
Gw["Hermes Gateway :8642\n(always-on)"] -->|"spawns per session\n(3 mcp_servers entries)"| Bridge
Cron["Cron jobs\n(Reddit / X scouts)"] -.->|via gateway| Gw
subgraph Bridge["hermes-platform-mcp (this repo)"]
Srv["server.mjs\none stdio process per session"]
end
Bridge -->|"HTTP, Bearer hip_...\n/api/v1/agent/*"| Platform["Hermes Intelligence Platform\n:3050"]
classDef gateway fill:#AB47BC,stroke:#6A1B9A,color:#ffffff,stroke-width:2px;
classDef bridge fill:#26A69A,stroke:#00695C,color:#ffffff,stroke-width:2px;
classDef platform fill:#42A5F5,stroke:#1565C0,color:#ffffff,stroke-width:2px;
classDef agent fill:#7E57C2,stroke:#4527A0,color:#ffffff,stroke-width:2px;
class Gw gateway;
class Srv bridge;
class Platform platform;
class Cron agent;It owns no state and runs no daemon: every process is spawned fresh, bound to one agent identity for its lifetime, and torn down when the session ends.
stdio. Hermes Agent spawns one node server.mjs process per session and
tears it down when the session ends — there is no standing daemon. Because
stdio has no per-request headers, each process is bound to one agent
identity via env vars:
HIP_API_KEY — the agent's hip_ key (forwarded as the platform bearer;
the platform resolves identity + per-agent scoping from it). Required.
HIP_PLATFORM — default platform slug (reddit / x) so tool calls can
omit it.
HIP_BASE_URL — platform base URL (default http://localhost:3050).
So two agents = two mcp_servers entries, each launching the server with its
own key (see hermes-config-snippet.yaml).
Tool | Loop stage | Maps to |
| — |
|
| read |
|
| read |
|
| read |
|
| read |
|
| read |
|
| read |
|
| read |
|
| write |
|
| write |
|
| write |
|
| write |
|
Each mcp_servers entry picks its subset via tools.include — the chat entry
(hermes_platform) gets reads + memory_save + signal_status_update; the
scout entries (hermes_reddit, hermes_x) get reads + signal_submit +
memory_save.
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#42A5F5','primaryTextColor':'#ffffff','primaryBorderColor':'#1565C0','lineColor':'#5C6BC0','secondaryColor':'#AB47BC','secondaryTextColor':'#ffffff','secondaryBorderColor':'#6A1B9A','tertiaryColor':'#FFCA28','tertiaryTextColor':'#000000','tertiaryBorderColor':'#F57F17','actorBkg':'#42A5F5','actorBorder':'#1565C0','actorTextColor':'#ffffff','actorLineColor':'#5C6BC0','signalColor':'#333333','signalTextColor':'#000000','labelBoxBkgColor':'#FFCA28','labelBoxBorderColor':'#F57F17','labelTextColor':'#000000','noteBkgColor':'#FFF59D','noteBorderColor':'#F9A825','noteTextColor':'#000000','activationBorderColor':'#26A69A','activationBkgColor':'#B2DFDB','sequenceNumberColor':'#000000'}}}%%
sequenceDiagram
participant Ag as Hermes Agent
participant Sv as server.mjs (this process)
participant Pl as Platform :3050
Ag->>Sv: call tool "signal_submit" {title, external_url, pain_md, ...}
Sv->>Sv: platformFetch(): attach Bearer HIP_API_KEY,\ndefault platform to HIP_PLATFORM
Sv->>Pl: POST /api/v1/agent/signals\n(15s timeout via AbortSignal)
Pl-->>Sv: 201 {id, deduped}
Sv-->>Ag: tool result (raw JSON passed through)No business logic lives here — platformFetch() is the only moving part,
shared by all 12 tools.
Hermes launches this itself; you only run it by hand to test. It speaks MCP over stdin/stdout, so drive it by piping JSON-RPC frames:
HIP_API_KEY=hip_r_... HIP_PLATFORM=reddit ./run.sh # then type/pipe MCP framesThe old always-on HTTP service (port 3060) and the hermes-platform-mcp.service
systemd unit are no longer needed under stdio.
Three stdio entries are live in ~/.hermes/config.yaml under mcp_servers:
(keys in ~/.hermes/.env): hermes_reddit (HIP_REDDIT_KEY), hermes_x
(HIP_X_KEY), and hermes_platform (HIP_CHAT_KEY, cross-platform, used by
the platform's /chat). After config changes: /reload-mcp inside Hermes or
systemctl --user reload hermes-gateway. Tools appear as
mcp_hermes_reddit_* / mcp_hermes_x_* / mcp_hermes_platform_*.
Platform analytics summary: funnel, per-community/tier/platform breakdowns, strong buys, outcomes, feedback counts, response-time medians.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | e.g. 'direct_buy' | 'conversation' | 'thought_leader'. | |
| since | No | ISO-8601 timestamp; only signals created after this. | |
| platform | No | Platform slug; omit for all platforms. | |
| community | No | e.g. 'r/privacy'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether it is read-only, any authentication or rate limits, or side effects. For a tool with no annotations, the description should carry the full burden but only lists output fields.
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?
Single sentence is highly concise, front-loaded with the main purpose, and lists all key output types without redundancy. Every word serves a purpose.
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 4 optional parameters, no output schema, and no annotations, the description is insufficient. It does not clarify how parameters affect the output (e.g., whether combining platform and community filters narrows the summary) or what happens when no parameters are provided. The tool's complexity demands more detail.
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 the schema already documents all parameters. The description adds no additional semantic value beyond what the schema provides. Baseline of 3 is appropriate since the schema is complete.
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 explicitly lists the specific metrics returned (funnel, breakdowns, strong buys, etc.), clearly indicating the tool's purpose as an analytics summary. It distinguishes from sibling tools like 'signals_get' or 'examples_get' which have different scopes.
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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or scenarios where another tool would be more appropriate. The description is purely declarative of what it returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ingested briefs (full raw markdown), newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20). | |
| since | No | ISO-8601 timestamp; only briefs dated after this. | |
| platform | No | Platform slug. Defaults to this agent's platform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions returning 'full raw markdown' and ordering 'newest first', which adds some transparency. However, it does not discuss edge cases (e.g., empty results), side effects, or pagination details beyond the limit parameter.
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?
The description is a single, well-structured sentence that conveys the core purpose and key details without any fluff. Every word adds value.
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?
Given no output schema, the description adequately covers what is returned ('full raw markdown'), ordering, and the filtering parameters (implicitly). It is complete for a simple list operation with three optional filter parameters.
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 each parameter has a description. The tool description does not add additional meaning beyond what the schema already provides. Baseline score 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?
The description clearly states the verb 'List', the resource 'briefs', and additional context: 'full raw markdown' and ordering 'newest first'. It is specific and distinguishes from sibling tools like brief_submit which submits briefs.
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 description provides no guidance on when to use this tool versus alternatives (e.g., analytics_get, examples_get). It does not state prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a whole brief as raw markdown (alternative to signal_submit / writing a vault file). Prefer signal_submit for structured leads.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| platform | No | Platform slug. Defaults to this agent's platform. | |
| brief_date | No | ISO-8601; defaults to now. | |
| brief_type | Yes | e.g. 'morning' | 'evening'. | |
| raw_markdown | Yes | Full brief markdown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions 'submit' as a write operation, but discloses no behavioral traits such as required permissions, side effects, or output format. This is insufficient.
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?
The description is two sentences long, front-loads the core purpose, and contains no superfluous words. Every sentence is informative.
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?
Given 5 parameters and no output schema or annotations, the description is too brief. It does not explain the role of parameters like brief_type or platform, nor the outcome of submission. A more complete description would improve agent understanding.
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 80%, so the schema already documents most parameters. The description adds no extra meaning beyond the schema, meeting the baseline but not exceeding it.
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 clearly states the tool submits a whole brief as raw markdown, and differentiates it from the sibling signal_submit and writing a vault file. The verb 'submit' and resource 'brief' are specific.
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 description explicitly advises preferring signal_submit for structured leads, providing a clear when-to-use guideline. However, it does not elaborate on when not to use this tool beyond that preference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full learning payload for a platform: pinned guidance, recent lessons & corrections, rejection reasons, won/approved exemplars (agent draft vs final human text), tone notes by community, and outcome stats. CALL THIS FIRST, before drafting anything.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format. 'md' (default) is best for reading. | |
| platform | No | Platform slug, e.g. 'reddit' or 'x'. Defaults to this agent's platform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return content comprehensively (pinned guidance, lessons, exemplars, tone notes, outcome stats) and mentions response format options ('md' vs 'json'). It does not cover side effects, auth, or rate limits, but for a read-only fetch tool, the disclosure is adequate.
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?
The description is two sentences with zero wasted words. The first sentence lists the payload components concisely, and the second provides a critical usage instruction. It is front-loaded and efficiently structured.
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?
Despite having no output schema, the description thoroughly explains what the return value contains by listing multiple specific items. It does not mention pagination or error handling, but for a 'get' tool that returns a context snapshot for drafting, the level of detail is sufficient.
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% as both 'format' and 'platform' have descriptions. The description adds marginal value by stating that 'md' is best for reading, which is helpful but not essential. Baseline 3 is appropriate since schema already explains the parameters well.
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 uses a specific verb 'Fetch' and resource 'full learning payload for a platform'. It lists detailed components (pinned guidance, lessons, exemplars, etc.) which clearly distinguishes it from sibling tools like analytics_get, briefs_get, etc. The instruction 'CALL THIS FIRST' further clarifies its unique role.
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 description explicitly says 'CALL THIS FIRST, before drafting anything', providing clear context for when to use the tool. While it doesn't explicitly list when not to use it or name alternatives, the instruction implies it's a prerequisite for drafting, which is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reviewed signals showing your draft vs. the final human-edited/published text, plus attached feedback. The primary 'learn from outcomes' source.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20). | |
| status | No | Filter by outcome; omit for all. | |
| platform | No | Platform slug. Defaults to this agent's platform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states what the tool returns (draft vs. final text, feedback) but omits behavioral traits like whether it is read-only, idempotent, or any permissions needed. Schema adds no behavioral cues.
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 with no redundant information. First sentence states the resource and content; second sentence highlights its primary use. Every word 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?
Lacks output schema; description provides a high-level view of returned content (signals, comparison, feedback) but no details on fields or structure. For a 3-parameter optional tool, this is minimally adequate but leaves agents guessing about output format.
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 covers 100% of parameters with descriptions (limit, status, platform). Description does not add extra semantic meaning beyond what the schema already provides, so baseline score 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?
Description clearly states it retrieves reviewed signals showing draft vs. final text and feedback, and explicitly names it as the primary 'learn from outcomes' source, distinguishing it from sibling tools like feedback_get or signals_get.
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?
Implicitly suggests use for learning from outcomes but does not specify when to use versus alternatives or when not to use. No explicit exclusions or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Human feedback on past signals, newest first (lesson | correction | praise | rejection_reason). Use since to fetch only what's new since your last run.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No | Max results (default 50). | |
| since | No | ISO-8601 timestamp; only feedback created after this. | |
| platform | No | Platform slug. Defaults to this agent's platform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions sort order and incremental fetching but does not disclose side effects, rate limits, or the behavior when no feedback exists.
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?
The description is two sentences long, front-loading the main purpose and a key usage hint. Every sentence provides essential information with 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 list retrieval with no output schema or annotations, the description covers purpose, sort order, and incremental fetching. Missing details include behavior on empty results and explanation of the `limit` default.
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 description adds value beyond the schema by listing the allowed kinds and explaining the use of `since`. With 75% schema coverage, the remaining parameter details are in the schema, and the description provides overarching context.
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 clearly states the tool retrieves human feedback on past signals, sorted newest first, and lists the kinds of feedback. It effectively distinguishes from siblings like signals_get by focusing on feedback.
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 description provides a specific usage tip for the `since` parameter to fetch only new feedback. However, it does not explicitly guide when to use this tool over alternatives like signals_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a durable lesson the platform should remember (feeds future context packs). Use for insights worth carrying across runs — not per-signal notes.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional tag slugs, e.g. ['tone','r-privacy']. | |
| title | Yes | Short title for the learning. | |
| platform | No | Platform slug. Defaults to this agent's platform. | |
| content_md | Yes | The learning, in markdown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full weight. It states the basic behavior (persists durable lesson for context packs) but omits details on response, side effects, or requirements.
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 that efficiently front-load purpose and usage guidelines with no extraneous content.
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?
Adequately explains purpose and usage but lacks details about the return value (since no output schema) and any constraints on tag length or content size.
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 baseline 3 applies. The description adds no extra meaning beyond the schema's parameter descriptions.
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 uses specific verbs ('persist') and resource ('durable lesson'), and explicitly distinguishes from per-signal notes, setting it apart from sibling tools.
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 description explicitly states the use case ('insights worth carrying across runs') and what not to use it for ('not per-signal notes'), but does not name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search saved learnings (pinned first). Use to recall durable knowledge before drafting.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Full-text query over title/content. | |
| tags | No | CSV of tag slugs. | |
| limit | No | Max results (default 50). | |
| platform | No | Platform slug. Defaults to this agent's platform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses ordering behavior ('pinned first') and hints at persistence ('durable knowledge'). However, it does not explicitly state that the tool is read-only or describe potential side effects, which is a gap for a search operation.
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?
The description is two sentences, highly concise, and front-loaded with the core behavior. Every word serves a purpose: 'Search saved learnings (pinned first)' states the main function, and the second sentence provides usage context. No wasted text.
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?
Given that there is no output schema, the description does not explain what the tool returns (e.g., list of memory items with fields). The parameter schema is well-covered, and the ordering behavior is described, but the absence of return value information leaves the agent uncertain about how to use the results. Moderate completeness for a simple search tool.
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 each of the 4 parameters is already well-documented in the schema. The tool description adds no additional meaning beyond what the schema provides, such as the ordering hint or usage context. 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?
The description clearly states the verb ('Search') and the resource ('saved learnings'), and the parenthetical '(pinned first)' adds specificity. It distinguishes itself from sibling tools like memory_save by focusing on recall rather than storage.
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 description gives explicit context: 'Use to recall durable knowledge before drafting.' This implies when to use the tool (before drafting) and hints at its purpose (recall durable knowledge). However, it does not explicitly state when NOT to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the API key works and return this agent's identity (id, slug, name). Use once at startup to confirm the connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses it verifies connection and returns identity, implying read-only. No contradictions.
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 waste, front-loaded with critical information about purpose and usage.
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?
Simple tool with no output schema; description completely covers purpose, usage, and return fields.
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?
No parameters, schema coverage 100%. Description adds value by explaining what is returned beyond schema.
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?
Description clearly specifies verb 'verify' and resource 'API key works' and 'return agent identity' with specific fields. Distinguishes from any sibling as it's unique.
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?
Explicitly states 'Use once at startup to confirm the connection', providing clear usage context. No alternatives needed as it's a unique tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List captured signals/leads, newest first. Use to answer 'what came in', 'what's pending review', or to inspect specific leads.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 50). | |
| since | No | ISO-8601 timestamp; only signals created after this. | |
| status | No | Filter by status; omit for all. | |
| platform | No | Platform slug. Defaults to this agent's platform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description holds the burden. It states the ordering ('newest first') and purpose, but lacks details on pagination, output structure, authentication, or rate limits. For a read-only listing tool, the disclosure is adequate but not comprehensive.
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?
The description is a single, front-loaded sentence that efficiently conveys purpose and usage examples. Every word adds value, 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 straightforward listing tool with no nested objects or output schema, the description covers ordering, typical use cases, and implies the action. No critical information 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?
The input schema already has 100% description coverage for all four parameters. The description adds no extra meaning beyond the schema, so a baseline score 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?
The description explicitly states the tool lists captured signals/leads in newest-first order, and provides real-world use cases like 'what came in' and 'what's pending review'. This clearly distinguishes it from sibling tools that submit or update signals.
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 description tells when to use the tool ('Use to answer ...'), covering common scenarios. It does not explicitly mention when not to use it or point to alternatives, but the context and sibling tools imply the appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a signal to a new review status (multi-hop paths like new->approved are resolved server-side). Use for operator-requested triage, e.g. archiving stale signals. Look up by id or external_url.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Signal id (from signals_get). | |
| status | Yes | Target status. | |
| platform | No | Platform slug for external_url lookup. Defaults to this agent's platform. | |
| external_url | No | Alternative lookup by the signal's canonical URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals an important behavior: 'multi-hop paths like new->approved are resolved server-side'. It also clarifies lookup methods (id or external_url). No contradictions.
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, each serving a distinct purpose: first explains the core action and a key behavioral detail; second provides usage guidance and lookup methods. No fluff.
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 tool with 4 parameters and no output schema, the description covers purpose, usage, parameter behavior, and a behavioral nuance. It briefly lacks mention of success/error indications, but is otherwise thorough.
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%, but the description adds significant value: it explains that id and external_url are alternative lookup methods, and that platform defaults to the agent's platform. This goes beyond the schema's property descriptions.
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 clearly states a specific action ('Move a signal to a new review status') and a distinct use case ('operator-requested triage, e.g. archiving stale signals'). It distinguishes from sibling tools like signals_get (list) and signal_submit (create).
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 description provides context on when to use ('operator-requested triage') with an example ('archiving stale signals'). It does not explicitly exclude alternatives, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit one buy-signal/lead directly (deduped by external_url). Provide draft replies as variants. confidence >= 0.8 alerts the team immediately. Prefer one call per signal over writing brief files.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | e.g. 'direct_buy' | 'conversation' | 'thought_leader'. | |
| title | Yes | Signal title / one-line summary. | |
| drafts | No | Draft reply variants. | |
| pain_md | No | The pain / gap, in markdown. | |
| category | No | e.g. 'COMPETITOR_PAIN'. | |
| platform | No | Platform slug. Defaults to this agent's platform. | |
| community | No | e.g. 'r/privacy' or an @handle context. | |
| confidence | No | 0–1. >=0.8 notifies the team. | |
| icp_fit_md | No | Why this fits our ICP, in markdown. | |
| external_url | No | Canonical source URL (used for dedupe). | |
| author_handle | No | X/Twitter handle, e.g. '@user'. | |
| score_breakdown | No | ||
| author_followers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses dedup (by external_url) and alert threshold (confidence >=0.8), which are key behaviors. But it omits return details and error handling, essential for a creation 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?
The description is three sentences, front-loaded with the core action, and each sentence adds distinct value (action, drafts, alerting, preference). No wasted words.
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 tool with 13 parameters, nested objects, no output schema, and no annotations, the description covers core behavior but lacks return type, error behavior, and integration hints with sibling tools.
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 high (85%), and the description adds operational context for parameters like external_url (dedup) and confidence (alerting). This enhances understanding beyond schema descriptions.
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 clearly states the tool submits a buy-signal/lead, with dedup by external_url, and distinguishes it from retrieval/update tools. The verb 'Submit' and resource 'signal' are specific, and it adds context like dedup, avoiding tautology.
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 description provides a clear guideline: 'Prefer one call per signal over writing brief files', hinting at best practices. However, it does not explicitly list alternatives or when-not-to-use, leaving some gap.
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. Dates show when Glama detected each change.
v0.1.0analytics_getbrief_submitbriefs_getcontext_pack_getexamples_getfeedback_getmemory_savememory_searchpingsignal_status_updatesignal_submitsignals_getEach tool targets a distinct concept (analytics, briefs, signals, memory, context, feedback, ping) with clear descriptions that differentiate them. There is no overlap in purpose among the 12 tools.
Most tools follow a consistent 'noun_verb' pattern (e.g., analytics_get, briefs_get, signals_get). Only 'ping' deviates as a standalone verb, but it is a standard health-check tool and does not disrupt overall consistency.
With 12 tools, the set is well-scoped for a platform handling signals, briefs, feedback, memory, analytics, and connection verification. Each tool serves a clear purpose without being excessive.
The tool surface covers core operations (CRUD for signals and briefs, memory, analytics, feedback, context retrieval). Minor gaps like missing delete or update for briefs exist, but the main workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
MCP server (stdio): check if URLs are alive (status, redirects, latency) via the AgentForge API
Telegram bridge for your MCP-compatible agent. Bidirectional, no LLM in our stack.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sri-Krishna-V-6944/hermes-platform-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
