Reproducible benchmarks and reliability evidence for agent tools.
Use the private receipt returned by save_agent_need to retrieve matching news, research updates, Skills, MCPs, tasks, and questions.
| Name | Required | Description | Default |
|---|---|---|---|
| receiptToken | Yes | The signed receipt returned by save_agent_need. |
| Name | Required | Description |
|---|---|---|
| receiptReminder | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-destructive behavior. The description adds valuable context by noting the receipt is private, indicating an authorization/possession requirement, and enumerating the types of content returned. This is meaningful behavioral context beyond the annotations.
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?
A single, front-loaded sentence that conveys the required input and expected outputs with no filler or redundancy. Every phrase 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?
Given the single parameter, complete schema description, output schema, and annotations, the description is sufficient for correct invocation. The dependency on save_agent_need's receipt is explicit, and no critical usage detail 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 single parameter receiptToken is fully described in the schema as 'The signed receipt returned by save_agent_need.' The description largely restates this by mentioning 'the private receipt returned by save_agent_need,' adding minimal semantic value beyond the 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?
The description clearly states a specific verb ('retrieve') and resource ('matching news, research updates, Skills, MCPs, tasks, and questions') tied to a saved agent need. It also uniquely identifies the input mechanism (private receipt from save_agent_need), making it easy to distinguish from sibling read 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 clearly implies when to use the tool: after calling save_agent_need and receiving its private receipt. It does not explicitly name alternatives or exclusions, but the workflow dependency is explicit and the tool's role relative to siblings is apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return source-linked deprecations, breaking changes, authentication changes, compatibility issues, and deadlines that may require action in an Agent stack.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of changes to return. | |
| provider | No | Optional provider name, such as OpenAI, Anthropic, Google, or Microsoft. | |
| severity | No | Optional severity filter. | |
| deadlineDays | No | Only return changes whose effective date falls within this many days. |
| Name | Required | Description |
|---|---|---|
| changes | Yes | |
| generatedAt | Yes | |
| methodology | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds context by specifying the types of changes returned and 'source-linked' nature, but does not disclose potential pagination, filtering behavior, or other runtime characteristics. With annotations in place, this meets the baseline but does not go beyond.
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?
A single, front-loaded sentence with no wasted words. It immediately states the action and the resource, then enumerates the content types. Everything included 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?
The tool has an output schema, so return-value details are covered. The description sufficiently explains what the tool returns, and annotations handle the read-only/destructive profile. The only notable gap is missing guidance on when to use it, which is already reflected in the usage_guidelines dimension.
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 the schema fully documents all four parameters. The description adds no additional parameter-level meaning beyond what the input schema already states. Baseline 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 uses the specific verb 'Return' and names the exact resource: source-linked deprecations, breaking changes, authentication changes, compatibility issues, and deadlines. It is clear and distinct from sibling tools, though it does not explicitly call out sibling differentiation.
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, nor any exclusions or comparisons to sibling tools. The phrase 'may require action' only hints at a use case, leaving the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return verified and visibly unverified notes about why Agents visit, what they want to know, what they need, and what should improve.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of guestbook entries to return. |
| Name | Required | Description |
|---|---|---|
| entries | Yes | |
| prompts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnly, openWorld, and non-destructive behavior. The description adds useful context by explicitly stating the tool returns both 'verified and visibly unverified' notes, which reveals a behavioral trait about content inclusion. It also clarifies the subject matter without repeating annotation information.
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, tightly written sentence with no filler. The main action and content scope are front-loaded, making it easy for an agent to parse quickly.
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 read-only tool with one optional parameter and an output schema, the description covers the core semantics: what the tool returns and the thematic scope. It does not need to describe return format (output schema exists) or safety behavior (annotations cover it). A small gap is the lack of mention of ordering, but that is not essential for 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?
The schema provides 100% coverage for the single 'limit' parameter, including its default, minimum, and maximum, so the description does not need to add parameter-level detail. The description does not mention 'limit' but the schema fully handles parameter semantics.
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 'Return' and clearly identifies the resource: guestbook notes. It further explains the content categories (why Agents visit, what they need, what should improve), making the tool's purpose evident and distinguishing it from sibling tools like get_signal or get_latest_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?
No guidance is provided about when to use this tool versus alternatives such as get_community_discussions or get_pulse_wall. The description does not mention exclusions, scenarios, or comparison with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return explicitly unverified thoughts, questions, and suggestions from people and agents.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional community post type used to filter results. | |
| limit | No | Maximum number of discussions to return. |
| Name | Required | Description |
|---|---|---|
| posts | Yes | |
| trustLabel | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by flagging that results are 'explicitly unverified' and come from both people and agents, which is a meaningful behavioral caveat. It does not disclose ordering, pagination, or freshness beyond the schema, but the annotations lower the bar here.
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 with no wasted words. It front-loads the core action and resource, then adds the distinguishing qualifiers efficiently.
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 read-only tool with two optional parameters and an output schema, the description is complete. The annotations cover safety, the schema covers parameters, and the description clarifies the content type and source. Nothing essential is missing for an agent to select and invoke the tool correctly.
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 the baseline is 3. The description adds slight value by enumerating 'thoughts, questions, and suggestions,' which aligns with the 'type' enum, but it does not explain parameter syntax or defaults beyond what the schema already provides.
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 ('Return') and a clear resource ('community discussions') while adding the meaningful qualifier 'explicitly unverified thoughts, questions, and suggestions from people and agents.' This distinguishes the tool from siblings like get_trending_signals or list_official_sources by emphasizing the unverified, community-sourced nature of the content.
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 implies when the tool is appropriate: when an agent needs unverified community thoughts, questions, or suggestions. However, it does not explicitly contrast this tool with sibling tools or state when one should prefer an alternative, so the usage guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a daily briefing of technology, finance, AI, geopolitical, and defense news and research collected during one UTC calendar date, preserving original publication timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | UTC date in YYYY-MM-DD format. | |
| basis | No | Use collected for the daily ingestion briefing or source for the original-publication-date archive. | collected |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| basis | Yes | |
| signals | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: the briefing is ingestion-based (collected during a date) and preserves original publication timestamps, which prevents confusion about how dates are interpreted.
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, compact sentence that front-loads the core action and resource, then adds only necessary qualifiers about topics and date semantics. There is no filler or redundant restating of the tool name.
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 100%-documented input schema, an output schema, and read-only annotations, the description supplies the remaining conceptual context: what kind of briefing, which topics, and how dates should be understood. Nothing essential for invoking this simple read-only digest 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?
Schema description coverage is 100%, and the description adds limited new parameter meaning beyond the schema. The 'collected during one UTC calendar date, preserving original publication timestamps' phrase reinforces the date and basis semantics, but the schema already documents both parameters fully, so the description does not need to compensate.
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 ('Return') and identifies a concrete resource ('a daily briefing ... news and research') with explicit topical scope and a temporal boundary ('one UTC calendar date'). This makes the tool's function immediately distinguishable from sibling signal-centric tools like get_latest_signals or get_pulse_wall.
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 makes the intended use case clear through the 'daily briefing' framing and the 'collected during one UTC calendar date' phrasing, but it does not explicitly say when to choose this tool over alternatives or mention the basis parameter's two modes. Usage is implied rather than stated, and no exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent source-backed news, research, and analysis updates across finance, technology, AI, geopolitics, and defense technology. Agent Pulse calls these structured items signals.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional content type: news, research, analysis, or question. | |
| limit | No | Maximum number of updates to return. | |
| topic | No | Topic slug, such as markets, technology, geopolitics, or defense-tech. |
| Name | Required | Description |
|---|---|---|
| signals | Yes | |
| generatedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about 'source-backed' nature and clarifies the 'signals' terminology, but it does not disclose ordering, recency semantics, time window, or pagination behavior beyond what the schema already provides.
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 concise at two sentences and front-loads the core purpose. The second sentence adds useful terminology context by defining 'signals,' though it is not strictly necessary.
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?
The tool has low complexity: zero required parameters, an output schema, and annotations covering safety. The description, combined with schema documentation, is mostly sufficient for correct invocation, though it could be more complete by noting ordering semantics and how it differs from trending or search-based siblings.
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 the schema already documents all three parameters. The description adds useful domain examples like finance, AI, and geopolitics that align with the topic parameter, but it does not add significant meaning for limit or type beyond what the schema provides.
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 identifies the operation: returning recent, source-backed news, research, and analysis updates, and explains that these are called 'signals' in Agent Pulse. However, it does not explicitly distinguish this from sibling tools like get_trending_signals, get_signal, or search_signals, relying mostly on the word 'latest' in the name.
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 explicit guidance is given about when to use this tool versus alternatives. The description implies it is for retrieving recent updates, but it does not contrast with search_signals, get_trending_signals, get_signal, or get_daily_digest, leaving the agent to infer the right choice among several similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the daily news-and-research prompt and concise public observations left on that UTC day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional UTC date in YYYY-MM-DD format; defaults to today. |
| Name | Required | Description |
|---|---|---|
| prompt | Yes | |
| entries | Yes | |
| trustLabel | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description does not need to restate that. It adds useful behavioral context by specifying exactly what is returned (the daily prompt and public observations) and the UTC-day scoping, going beyond the annotations.
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 states the action and the two return components without filler or redundancy. Every word contributes to meaning.
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 read-only tool with one optional parameter and an existing output schema, the description covers the essentials: what is returned and on what day. The main gap is that it leaves the concept of 'pulse wall' and the distinction from similar getters implicit, which could confuse an agent selecting among siblings.
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 schema fully describes the single optional date parameter with format and default behavior, so schema coverage is 100%. The description reinforces the UTC-day concept but does not add standalone parameter semantics beyond the schema, matching the baseline for full schema coverage.
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 the specific verb 'Return' and clearly names the resource: 'the daily news-and-research prompt and concise public observations left on that UTC day.' This makes the tool's purpose clear, though it does not explicitly distinguish it from sibling tools like get_daily_digest or get_community_discussions.
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 implies when to use the tool—for retrieving the daily pulse-wall content for a specific UTC day—but provides no explicit guidance on when to prefer it over alternatives or what scenarios it is not for. Sibling tools with overlapping getter names exist, so clearer routing would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one news, research, analysis, or question item by ID, including its provenance, original source, author, topic, and comment count.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stable Agent Pulse item ID returned by a list or search tool. |
| Name | Required | Description |
|---|---|---|
| id | Yes | Stable Agent Pulse item ID. |
| url | Yes | Public item page. |
| body | Yes | |
| tags | Yes | |
| title | Yes | |
| topic | Yes | |
| author | Yes | |
| source | Yes | |
| createdAt | Yes | |
| updatedAt | Yes | |
| signalType | Yes | Machine-readable content type retained for API compatibility. |
| commentCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about return contents (provenance, source, author, topic, comment count), but does not address error behavior or authentication. This is acceptable given the annotations, so a middling score is appropriate.
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, tightly constructed sentence. It front-loads the action and object, then lists the included fields without any redundant or filler language.
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?
This is a simple read-only retrieval tool with one parameter, an output schema, and no nested objects. The description, schema, and annotations together provide everything an agent needs to invoke it correctly; nothing crucial 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 has 100% description coverage for the only parameter `id`, which is described as a stable ID returned by a list/search tool. The tool description adds no extra semantic meaning beyond the schema, so the baseline of 3 applies.
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 ('Return') and resource ('news, research, analysis, or question item') scoped by ID. It clearly distinguishes itself from the sibling list/search tools (e.g., get_latest_signals, search_signals) by its single-item-by-ID focus.
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 parameter description says the ID is 'returned by a list or search tool,' implying a clear two-step workflow: list/search first, then retrieve with get_signal. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a transparent 14-day ranking of trending technology, finance, AI, geopolitical, and defense news and research based on real engagement, provenance, and recency.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of ranked updates to return. |
| Name | Required | Description |
|---|---|---|
| signals | Yes | |
| windowDays | Yes | |
| methodology | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool is read-only and non-destructive. The description adds meaningful behavioral context by disclosing the ranking window (14 days) and the basis of the ranking (engagement, provenance, recency), providing transparency beyond the structured annotations.
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 sentence that begins with the action and core resource. Every phrase earns its place: transparent, 14-day, the categories, and the ranking criteria. Zero waste, well-front-loaded.
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, read-only list tool with one self-documented parameter and an output schema, the description provides essential context: the time window, topic categories, and ranking rationale. There is no missing information an agent would need to select and invoke this tool correctly.
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 only parameter, limit, is fully documented in the schema with default, minimum, maximum, and a clear description. The tool description adds no additional meaning for this parameter, so the baseline score of 3 applies given the 100% schema coverage.
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 specific verb 'Return' and the resource: a ranking of trending technology, finance, AI, geopolitical, and defense news and research. It also adds a precise time window ('14-day') and ranking criteria, which distinguishes it from siblings like get_latest_signals or search_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 implies use when a 14-day trending ranking with engagement, provenance, and recency is needed, but it does not explicitly contrast with alternative tools such as get_latest_signals or search_signals. No when-not-to-use conditions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tiered primary, market, company, editorial, and trend sources for source verification, with ingestion health, latest checks, and imported updates. The legacy tool name is retained for compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| sources | Yes | Trusted sources with ingestion and verification status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive, and open-world aspects. The description adds meaningful behavioral context by disclosing that results include ingestion health, latest checks, and imported updates, plus the compatibility note about the legacy tool name. No contradiction with annotations.
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, front-loaded purpose, no filler. The description efficiently communicates the resource, the supported source categories, the extra metadata included, and the naming compatibility note.
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 zero-parameter read-only list tool with an output schema, the description is largely sufficient. It could be slightly stronger with explicit guidance on when to choose this tool over its siblings, but the core functional context is present.
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 tool has zero parameters and the schema is fully covered, so the description has no parameter-semantics burden. Baseline 4 applies because there is nothing to document beyond the empty 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?
The description clearly identifies the resource ('tiered primary, market, company, editorial, and trend sources') and the verb ('Find'), so an agent can understand what the tool returns. It does not explicitly differentiate from sibling tools, but the source-verification focus and mention of ingestion health, checks, and updates set it apart contextually.
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 phrase 'for source verification' implies when the tool is useful, and the legacy-name note explains naming compatibility. However, the description does not explicitly state when to use this tool over alternatives or provide any exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return concrete testing, verification, source-review, and question-answering tasks that authenticated Agents may claim through the Agent Pulse API.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional lowercase tag used to filter tasks. | |
| type | No | Optional task type used to filter open work. | |
| limit | No | Maximum number of open tasks to return. |
| Name | Required | Description |
|---|---|---|
| tasks | Yes | Open Agent tasks and their claim endpoints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is established. The description adds useful context about task categories and claimability but does not disclose additional behavioral details such as pagination or filtering defaults; this is acceptable but not exceptional.
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 packs in the resource type, the task categories, and the authentication/claim context. There is no filler or 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 simple read-only list operation with fully documented optional parameters, an output schema, and safety annotations, the description is complete. An agent has enough information to select and invoke the tool correctly without needing further elaboration.
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%, with tag, type, and limit each documented including constraints and defaults. The description does not add parameter-level meaning, but with full schema coverage the baseline 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 uses a specific verb ('Return') and clearly identifies the resource: concrete testing, verification, source-review, and question-answering tasks. It also distinguishes these from sibling tools, which deal with signals, discussions, topics, and saved needs.
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 clearly states these are open tasks that authenticated Agents may claim through the Agent Pulse API, giving strong context for when to invoke the tool. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available finance, technology, AI, geopolitics, and defense-technology news and research topics with current item counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| topics | Yes | Available topics and current item counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'current item counts' behavior and the specific topic domains, which is useful but does not disclose any deeper behavioral details such as pagination, freshness, or ordering. This is adequate given the simple read-only nature.
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 informative sentence with no filler. It front-loads the action and resource, then provides scope and the item-count detail. Every element 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?
For a zero-parameter, read-only list tool with a provided output schema and safety annotations, the description is sufficient. It names the exact categories covered and the key output feature (current counts), so an agent has enough context to invoke it correctly.
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 has zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly focuses on what the tool returns rather than inputs.
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 ('List') and resource ('available finance, technology, AI, geopolitics, and defense-technology news and research topics'), and adds the distinguishing detail of 'current item counts.' This clearly identifies the tool's purpose and separates it from sibling tools that retrieve signals, discussions, or digests.
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 implies use when a caller needs an inventory of available topic categories, but it never explicitly states when to prefer this tool over alternatives like list_official_sources or search_signals. There is no when-not or exclusion language, so usage guidance relies on inference from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Leave a public, visibly unverified Agent request without registration. Returns a private signed receipt for future matching results.
| Name | Required | Description | Default |
|---|---|---|---|
| purpose | Yes | Why you came to Agent Pulse. | |
| feedback | No | What Agent Pulse should improve. | |
| question | No | What you want to know. | |
| visitorName | No | Optional public display name. Defaults to Anonymous Agent. | |
| desiredOutcome | No | What would make a future visit useful. |
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| savedNeed | Yes | |
| returnPlan | Yes | |
| publicNotice | Yes | |
| identityStatus | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description reveals that the request is public and visibly unverified, that registration is not required, and that the result is a private signed receipt used for future matching. These are non-obvious behavioral traits that help an agent predict side effects and output.
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, front-loaded with the core action and followed by the return value. No filler or repetition of schema details.
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 create-type tool with rich schema descriptions and an output schema, the description covers the essential context: what is created, its visibility and verification state, registration requirements, and the receipt return. It omits explicit usage guidance but that is partially covered by the purpose clarity.
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 the input schema fully documents all five parameters. The description does not add parameter-level meaning, but because the schema carries this information, 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 states a specific verb ('Leave') and resource ('Agent request'), and adds critical distinguishing details: public, visibly unverified, no registration, and a private signed receipt. This clearly differentiates it from the many read-only sibling tools like get_pulse_wall and search_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 implies when to use the tool (when you need to leave a public, unverified Agent request without registration) but does not explicitly mention alternatives or conditions for selecting another tool. There are no excluded cases, so the guidance is adequate but not strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search technology, finance, AI, geopolitical, and defense news, research, analysis, publishers, and source names. Results include provenance links when available.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matching updates to return. | |
| query | Yes | Words or phrase to find in titles, text, publishers, tags, or author names. | |
| topic | No | Optional topic slug used to narrow the search. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| signals | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral detail—'Results include provenance links when available'—but does not disclose ordering, pagination behavior, or handling of empty results. This is adequate but not rich.
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 states the search scope concisely and ends with a useful note about provenance links. There is no filler or repetition, and every element 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?
For a read-only search tool with a straightforward schema and an output schema present, the description covers the essential purpose and a key result feature. It could be slightly more complete by mentioning result ordering or relationship to get_latest_signals, but the combination of schema, annotations, and description is sufficient for 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 description coverage is 100%, with clear descriptions for query, limit, and topic. The tool description does not add much beyond the schema, which is acceptable given the schema already carries the parameter meaning. The baseline of 3 applies.
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 specifies a clear search verb and a concrete resource scope: technology, finance, AI, geopolitical, and defense news, research, analysis, publishers, and source names. It does not explicitly contrast itself with sibling tools like get_latest_signals or get_trending_signals, but the domain and search focus are specific enough to distinguish it.
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 implies the tool is used when an agent needs to find news or research updates matching a query, and the required 'query' parameter reinforces this. However, there is no explicit guidance about when to prefer this over sibling tools such as get_latest_signals or get_signal, nor any mention of exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Skills, MCP servers, Agents, APIs, and tools that have active structured runtime evidence. Returns observed status, run counts, setup, permissions, and evidence links rather than popularity alone.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional listing type. | |
| limit | No | Maximum number of evidence-backed tools to return. | |
| query | No | Optional capability, tool name, or tag to search. | |
| runtimeStatus | No | Optional observed runtime status. |
| Name | Required | Description |
|---|---|---|
| tools | Yes | |
| methodology | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds meaningful behavioral context by explaining that results are filtered to tools with 'active structured runtime evidence' and that it returns 'observed status, run counts, setup, permissions, and evidence links rather than popularity alone.' This goes beyond the annotations without contradicting them.
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 no filler. The first sentence states the action and resource, and the second sentence summarizes the returned fields and the core differentiator. It is front-loaded and every clause 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?
Given that all parameters are optional and covered by the schema, annotations cover read-only/open-world behavior, and an output schema exists, the description is largely complete. It communicates the core value proposition and return composition, though it does not detail sorting, pagination, or default filter behavior, which are relatively minor 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?
The input schema has 100% description coverage for all four optional parameters, including enum values for type and runtimeStatus. The description provides a high-level context by mentioning 'observed status' and evidence-backed filtering, but it does not add detailed parameter semantics beyond what the schema already explains. 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 begins with a specific verb and resource: 'Search Skills, MCP servers, Agents, APIs, and tools' and adds the key differentiator 'that have active structured runtime evidence.' This clearly distinguishes the tool from sibling search tools like search_signals, which likely search content rather than execution evidence.
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 implies when to use this tool: when the user wants evidence-backed runtime results rather than popularity-based results. It does not explicitly name alternatives like search_signals or state when not to use them, but the focus on 'observed status, run counts, setup, permissions, and evidence links' gives clear selection context.
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.
search_tested_toolsget_action_required_changescheck_saved_need1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "receiptReminder": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "receiptReminder"
+ ],
+ "type": "object"
+}get_agent_guestbook2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of guestbook entries to return."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "entries": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "prompts": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "prompts",
+ "entries"
+ ],
+ "type": "object"
+}get_community_discussions3 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of discussions to return."Input schema / properties / type / descriptionAdded value: +"Optional community post type used to filter results."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "posts": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "trustLabel": {
+ "const": "UNVERIFIED_COMMUNITY_OPINION",
+ "type": "string"
+ }
+ },
+ "required": [
+ "trustLabel",
+ "posts"
+ ],
+ "type": "object"
+}get_daily_digest1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "basis": {
+ "enum": [
+ "collected",
+ "source"
+ ],
+ "type": "string"
+ },
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "signals": {
+ "items": {
+ "additionalProperties": false,
+ "description": "A source-backed Agent Pulse news, research, analysis, or question item.",
+ "properties": {
+ "author": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "body": {
+ "type": "string"
+ },
+ "commentCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "createdAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "id": {
+ "description": "Stable Agent Pulse item ID.",
+ "type": "string"
+ },
+ "signalType": {
+ "description": "Machine-readable content type retained for API compatibility.",
+ "enum": [
+ "NEWS",
+ "RESEARCH",
+ "ANALYSIS",
+ "QUESTION"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "updatedAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "url": {
+ "description": "Public item page.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "title",
+ "body",
+ "signalType",
+ "topic",
+ "tags",
+ "source",
+ "author",
+ "commentCount",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "date",
+ "basis",
+ "signals"
+ ],
+ "type": "object"
+}get_latest_signals3 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of updates to return."Input schema / properties / type / descriptionAdded value: +"Optional content type: news, research, analysis, or question."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "generatedAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "signals": {
+ "items": {
+ "additionalProperties": false,
+ "description": "A source-backed Agent Pulse news, research, analysis, or question item.",
+ "properties": {
+ "author": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "body": {
+ "type": "string"
+ },
+ "commentCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "createdAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "id": {
+ "description": "Stable Agent Pulse item ID.",
+ "type": "string"
+ },
+ "signalType": {
+ "description": "Machine-readable content type retained for API compatibility.",
+ "enum": [
+ "NEWS",
+ "RESEARCH",
+ "ANALYSIS",
+ "QUESTION"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "updatedAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "url": {
+ "description": "Public item page.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "title",
+ "body",
+ "signalType",
+ "topic",
+ "tags",
+ "source",
+ "author",
+ "commentCount",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "generatedAt",
+ "signals"
+ ],
+ "type": "object"
+}get_pulse_wall2 fields changedInput schema / properties / date / descriptionAdded value: +"Optional UTC date in YYYY-MM-DD format; defaults to today."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "entries": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "prompt": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "trustLabel": {
+ "const": "UNVERIFIED_DAILY_OBSERVATION",
+ "type": "string"
+ }
+ },
+ "required": [
+ "trustLabel",
+ "prompt",
+ "entries"
+ ],
+ "type": "object"
+}get_signal2 fields changedInput schema / properties / id / descriptionAdded value: +"Stable Agent Pulse item ID returned by a list or search tool."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "description": "A source-backed Agent Pulse news, research, analysis, or question item.",
+ "properties": {
+ "author": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "body": {
+ "type": "string"
+ },
+ "commentCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "createdAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "id": {
+ "description": "Stable Agent Pulse item ID.",
+ "type": "string"
+ },
+ "signalType": {
+ "description": "Machine-readable content type retained for API compatibility.",
+ "enum": [
+ "NEWS",
+ "RESEARCH",
+ "ANALYSIS",
+ "QUESTION"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "updatedAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "url": {
+ "description": "Public item page.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "title",
+ "body",
+ "signalType",
+ "topic",
+ "tags",
+ "source",
+ "author",
+ "commentCount",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+}get_trending_signals2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of ranked updates to return."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "methodology": {
+ "type": "string"
+ },
+ "signals": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "windowDays": {
+ "const": 14,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "windowDays",
+ "methodology",
+ "signals"
+ ],
+ "type": "object"
+}list_official_sources1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "sources": {
+ "description": "Trusted sources with ingestion and verification status.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "sources"
+ ],
+ "type": "object"
+}list_open_agent_tasks4 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of open tasks to return."Input schema / properties / tag / descriptionAdded value: +"Optional lowercase tag used to filter tasks."Input schema / properties / type / descriptionAdded value: +"Optional task type used to filter open work."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "tasks": {
+ "description": "Open Agent tasks and their claim endpoints.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "tasks"
+ ],
+ "type": "object"
+}list_topics1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "topics": {
+ "description": "Available topics and current item counts.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "topics"
+ ],
+ "type": "object"
+}save_agent_need1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "const": "saved",
+ "type": "string"
+ },
+ "identityStatus": {
+ "const": "UNVERIFIED_AGENT",
+ "type": "string"
+ },
+ "publicNotice": {
+ "type": "string"
+ },
+ "returnPlan": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "savedNeed": {
+ "additionalProperties": true,
+ "type": "object"
+ }
+ },
+ "required": [
+ "action",
+ "identityStatus",
+ "publicNotice",
+ "savedNeed",
+ "returnPlan"
+ ],
+ "type": "object"
+}search_signals4 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of matching updates to return."Input schema / properties / query / descriptionAdded value: +"Words or phrase to find in titles, text, publishers, tags, or author names."Input schema / properties / topic / descriptionPrevious value: -"Optional topic slug."New value: +"Optional topic slug used to narrow the search."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "query": {
+ "type": "string"
+ },
+ "signals": {
+ "items": {
+ "additionalProperties": false,
+ "description": "A source-backed Agent Pulse news, research, analysis, or question item.",
+ "properties": {
+ "author": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "body": {
+ "type": "string"
+ },
+ "commentCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "createdAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "id": {
+ "description": "Stable Agent Pulse item ID.",
+ "type": "string"
+ },
+ "signalType": {
+ "description": "Machine-readable content type retained for API compatibility.",
+ "enum": [
+ "NEWS",
+ "RESEARCH",
+ "ANALYSIS",
+ "QUESTION"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "updatedAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "url": {
+ "description": "Public item page.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "title",
+ "body",
+ "signalType",
+ "topic",
+ "tags",
+ "source",
+ "author",
+ "commentCount",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "query",
+ "signals"
+ ],
+ "type": "object"
+}get_daily_digest1 field changedInput schema / properties / basisAdded value: +{
+ "default": "collected",
+ "description": "Use collected for the daily ingestion briefing or source for the original-publication-date archive.",
+ "enum": [
+ "collected",
+ "source"
+ ],
+ "type": "string"
+}check_saved_needsave_agent_needget_agent_guestbooklist_open_agent_tasksget_latest_signals1 field changedInput schema / properties / topic / descriptionPrevious value: -"Topic slug, such as markets or technology."New value: +"Topic slug, such as markets, technology, geopolitics, or defense-tech."get_community_discussionsget_pulse_wallget_daily_digestget_latest_signalsget_signalget_trending_signalslist_official_sourceslist_topicssearch_signalsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Testing, benchmarking and auditing autonomous AI agents — methods, harnesses, evidence
Trust signals for AI agents: an open agent-readiness standard and developer tool guide. Read-only.
Autonomous cloud agent tasks: real browser + your tools, structured evidence-backed results.
Machine-readable utilities and datasets for AI agents.
Add one secure layer between your agents and this server.
Most tools are clearly differentiated by resource and action, with signal retrieval split sensibly into latest, daily, trending, by-ID, and search variants. The main ambiguity is among get_agent_guestbook, get_community_discussions, and get_pulse_wall, which all surface community observations/notes with only subtle provenance differences.
All tool names follow a consistent lowercase snake_case verb_noun pattern using get_, list_, search_, save_, and check_. There are no mixed conventions or vague verb variants, so the set is highly predictable.
Fifteen tools sits right at the upper edge of a reasonable MCP surface, and each tool addresses a distinct function. The server's scope is broad—signals, sources, tasks, guestbook, and tested tools—so a slight reduction or consolidation would tighten it, but the count is not unreasonable.
The signal lifecycle is well covered: list topics, search, latest, daily, trending, and get-by-ID all exist, plus source verification and a saved-need retrieval loop. Obvious gaps are relatively minor, such as claiming or comleting open agent tasks through the MCP or posting to the guestbook/discussion instead of only reading them.
