A
licenseNot graded
qualityB
maintenanceProvides crypto market intelligence tools, reference resources, and prompt templates for sentiment analysis, mindshare tracking, social intelligence, and more.
54 npm
5
MIT
AIXBT
Server Details
Crypto market intelligence for Projects, Topics, Intel, Reports, and Clusters.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.5/5.0
Scored across 12 tools
Disambiguation5/5
Each tool targets a distinct resource and action: get_* retrieves a single entity, list_* searches or enumerates collections, and *_series returns historical attention data. The descriptions clearly differentiate similar pairs like get_intel vs list_intel and get_project vs get_project_series.
Naming Consistency4/5
Almost all tools follow a consistent snake_case verb_noun pattern with get_ and list_ prefixes. The single tool 'me' breaks the convention, though it is a recognizable auth-check name.
Tool Count5/5
12 tools is well within the ideal range and each earns its place by covering a distinct facet of crypto intelligence. There is no obvious redundancy or padding.
Completeness4/5
The surface provides comprehensive read-only coverage for intel, projects, topics, reports, clusters, vocabulary, and credential checks. Minor gaps exist, such as no list_reports or get_cluster detail, but core workflows are supported.
Available Tools
12 toolsget_intelGet intel detailsCRead-onlyInspect
Get one development with its sources and context.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact Intel item id returned by list_intel, not its project.id | |
| activity | No | Activity rows to include: all (default), source observations only, or none |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes |
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the result embeds sources and context (an expansion behavior beyond a plain record fetch), which is genuinely useful, but says nothing about permissions, size of the embedded payload, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single economical sentence with no filler, and the core action leads. It is arguably too terse, but nothing is wasted or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the annotation covers safety. What remains thin is orientation: the description never ties 'development' to the intel concept or explains the consequence of the activity enum, leaving a minor but real gap for a tool whose id semantics are already error-prone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema is unusually good — it warns that the id must be the Intel item id 'not its project.id' and enumerates the activity modes. The description adds no parameter meaning beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb (Get) and a singular resource, but calls the resource a 'development' while the tool and its sibling list_intel deal in 'intel' items, so the agent must infer the two are the same thing. It does clarify the retrieval is one item including its sources and context, which is more than a bare restatement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no alternatives named. The pairing with list_intel in the sibling list implies a follow-up single-item fetch, but nothing in the description says when this is preferable or what conditions require it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_projectGet project detailsARead-onlyInspect
Get a Project with recent Intel and related Projects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| idOrSlug | Yes | Project ID or slug; slug aliases resolve |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds behavioral detail about returning 'recent Intel and related Projects', which is helpful beyond the annotations. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the primary action and includes key qualifiers. No wasted words; efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, output schema present), the description provides sufficient context for an agent to understand what the tool returns. The mention of 'recent Intel and related Projects' adds value without needing to duplicate the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of idOrSlug. The tool description adds no additional parameter semantic value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single project along with recent intel and related projects, distinguishing it from sibling tools like list_projects (which lists projects) or get_intel (which gets only intel). However, it could be more precise about the scope of 'recent' and what 'related Projects' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need a single project with associated intel and related projects, but does not explicitly state when to use it versus alternatives like list_projects or get_project_series. No guidance on exclusions or preconditions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_project_seriesGet project historyBRead-onlyInspect
Get recent attention history for a Project.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of time window (ISO 8601) | |
| from | No | Start of time window (ISO 8601) | |
| measure | Yes | trend for hourly scores; rank for recorded Trend-rank changes | |
| idOrSlug | Yes | Project ID or slug; slug aliases resolve |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, covering the safety profile. The description adds 'recent' implying a time constraint but does not elaborate on bounds, pagination, or output behavior. With annotations present, the description is adequate but adds little beyond the abstract term 'attention history.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. It contains no unnecessary words or redundancy. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are covered), 4 parameters with optional time window, and an enum, the description is adequate but incomplete. It does not mention the from/to filtering capability or default behavior. 'Recent' is vague, leaving the agent to infer that from/to control the window.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 four parameters. The description adds no additional meaning about parameters (e.g., default time windows or the meaning of 'trend' vs 'rank'). Baseline 3 is appropriate given the schema handles the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'recent attention history for a Project,' using a specific verb and resource. It implies time-series data, which distinguishes it from sibling tools like get_project (static details) and get_topic_series (topic attention). However, it could more explicitly define 'attention history' or contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of appropriate scenarios, prerequisites, or exclusions (e.g., 'use get_project for static info, get_topic_series for topics'). The agent receives no help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reportGet topic reportBRead-onlyInspect
Get a published AIXBT report with its sources.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Report ID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one behavioral detail beyond that: only *published* reports are retrievable and sources are bundled in the response. It says nothing about error behavior for unpublished/unknown IDs, so it is only marginally above what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. It is efficient, though extremely brief — there is little structure to evaluate beyond the single clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described, and the single parameter is fully covered by the schema, so the description is nearly complete. The only missing piece is any signal about what happens when the ID is unknown or the report is unpublished.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single required 'id' string parameter, so the schema already documents the input fully. The description adds no format, prefix, or validity detail beyond the schema, which is the expected baseline of 3 in this situation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Get a ... report') and adds useful scope with 'published' and 'with its sources', which distinguishes it from sibling getters like get_topic or get_project. It stops short of explicitly naming which sibling to use instead, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites, and no reference to the many sibling retrieval tools (get_intel, get_project, get_topic, etc.). The agent must infer from the name alone when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topicGet topic detailsARead-onlyInspect
Get one current Topic with its recent context.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topicId | Yes | Topic ID from list_topics |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the agent knows this is a safe read operation with bounded context. The description adds 'with its recent context,' which hints at temporal scoping, but does not elaborate on the behavior (e.g., how 'recent' is defined, or whether the topic is updated). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. It is appropriately sized for a tool with one parameter and clear purpose, though it could be slightly more specific without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, clear schema, annotations for safety, and an output schema present), the description is adequate. It explains the core function and the 'recent context' aspect. The output schema exists, so return value details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter topicId has a pattern and description referencing list_topics). The description does not add any new meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get one current Topic with its recent context.' This clearly identifies the verb (Get), the resource (Topic), and distinguishes it from siblings like get_report or list_topics. The mention of 'recent context' adds specificity, but the scope is not fully elaborated (e.g., what constitutes 'context').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving a single topic, contrasting with list_topics (which likely returns many). However, there is no explicit guidance on when to use this tool versus siblings like get_topic_series or get_intel, nor any mention of prerequisites (e.g., topicId from list_topics is already in the schema).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topic_seriesGet topic historyARead-onlyInspect
Get recent attention history for a Topic.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of time window (ISO 8601) | |
| from | No | Start of time window (ISO 8601) | |
| measure | Yes | trend for hourly scores; rank for recorded Trend-rank changes | |
| topicId | Yes | Topic ID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the tool is clearly safe for reading. The description adds the behavioral context that this retrieves 'history' (time-series data), which is beyond what the annotations specify. There is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. It front-loads the key action and subject. It could potentially add a bit more context (e.g., what 'recent' means) without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but present), the description need not detail return values. However, it provides no guidance on time window handling or the interpretation of 'recent', nor does it explain the two measure options. The description is adequate for a tool with strong schema coverage and annotations, but leaves the agent guessing on default behavior (e.g., what happens if 'from' or 'to' is omitted?)
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all four parameters with descriptions and constraints. The description adds minimal parameter-specific value but confirms the overall intent ('recent attention history'). The measure enum is well-described, and date/time parameters are clearly specified. Baseline 3 plus minor extra context justifies 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent attention history for a Topic' clearly identifies the action (get) and resource (attention history for a topic). However, it uses the vague term 'recent' which is not precisely defined, and among siblings like 'get_topic' (which likely returns current state) and 'get_project_series', this does not strongly distinguish itself beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving time-series data ('recent attention history'), suggesting it is for historical queries rather than current state. However, it provides no explicit guidance on when to use this tool versus alternatives like 'get_topic' (current state), 'get_intel' (different resource), or 'get_report'. No exclusion criteria or context signals are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vocabularyGet filter vocabularyBRead-onlyInspect
Get current supported filter values.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds that the values are 'current supported,' implying dynamic or time-sensitive data, but lacks details on authentication, rate limits, or what 'current' means in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and efficient, though it could benefit from slightly more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (0 parameters, output schema exists) and the presence of many sibling tools, the description is too minimal. It does not explain what 'filter values' are, how they are used, or how this tool fits into a workflow. The output schema may provide structure, but the description lacks guidance for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100%. The description does not need to explain parameters; the baseline of 3 is appropriate as it adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current supported filter values' clearly states the tool retrieves filter vocabulary, which is a specific resource. It distinguishes from siblings like 'get_intel' or 'get_project' that retrieve different data types, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as using this tool to populate filter options before querying other tools, 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.
list_clustersList audience clustersARead-onlyInspect
List audience communities contributing to crypto attention.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| universe | No | Market universe (default: crypto) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation. The description adds specificity that it lists 'audience communities contributing to crypto attention', which clarifies the scope beyond the annotations. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 7 words, which is concise and to the point. It front-loads the verb and resource. However, its brevity means it lacks detail that could add value, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 optional parameter, no required params, output schema present), the description is minimally adequate. The output schema likely covers the return structure, and annotations cover safety. However, the description could explain what 'audience clusters' are or how the 'universe' parameter affects results. For a simple tool, it is sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the 'universe' parameter with enum values and a description. The description adds no additional parameter semantics beyond what the schema provides, such as default behavior (default: crypto) which is not in the description. Baseline 3 is appropriate since the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'list' and the resource 'audience clusters', but qualifies it with 'contributing to crypto attention', which narrows the scope and distinguishes it vaguely from siblings. However, it does not fully clarify what 'clusters' are in this context, and the sibling tools like 'list_projects' or 'list_topics' suggest overlapping listing functionality. The description is clear but lacks distinctiveness from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving audience clusters related to crypto attention, and the input schema hints at filtering by 'universe' (crypto or tradfi). However, there is no explicit guidance on when to use this tool versus alternatives like 'list_intel' or 'list_projects'. No when-not-to-use or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_intelSearch crypto intelCRead-onlyInspect
Search recent crypto developments using text and filters.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Order by first detection (default) or latest reinforcement | |
| limit | No | Results per page (default and maximum: 50) | |
| names | No | Comma-separated Project names | |
| cursor | No | Cursor returned in meta.nextCursor from the previous page | |
| grades | No | ||
| search | No | Any text to match across Project identity and Intel content; combines with all filters | |
| address | No | Token contract address | |
| tickers | No | Comma-separated tickers | |
| activity | No | Activity rows to include: all (default), source observations only, or none | |
| xHandles | No | Comma-separated X handles | |
| assetTypes | No | Comma-separated asset types; use get_vocabulary to list them | |
| categories | No | Comma-separated Intel category names; use get_vocabulary and choose intelCategories[].name | |
| clusterIds | No | Comma-separated cluster IDs | |
| projectIds | No | Comma-separated Project IDs | |
| sentiments | No | Comma-separated sentiments: positive, neutral, negative | |
| minClusters | No | Minimum number of community clusters represented | |
| projectSlugs | No | Comma-separated Project slugs | |
| detectedAfter | No | Detected at or after this time (ISO 8601) | |
| detectedBefore | No | Detected at or before this time (ISO 8601) | |
| projectRanking | No | Only return Intel for Projects in the current trend ranking | |
| reinforcedAfter | No | Reinforced at or after this time (ISO 8601) | |
| reinforcedBefore | No | Reinforced at or before this time (ISO 8601) | |
| hasOfficialSource | No | Set true to return only Intel with an official Project source |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds no behavioral context beyond 'Search recent crypto developments'. It fails to mention pagination (cursor/limit), default sorting, or that results are a filtered list. For a search tool with 23 parameters, the description should disclose key behavioral traits like pagination and default ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 8 words. It avoids redundancy and is easy to parse. However, given the tool's complexity (23 parameters), it is arguably too sparse and could be expanded slightly to include core features without losing conciseness. Still, it earns a 4 for being efficient and without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 23 parameters, a good description should provide an overview of the main filtering dimensions (e.g., text, project, date, sentiment, asset type) and pagination behavior. The current description is too vague: 'text and filters' does not convey the rich filter set or the fact that results are paginated via cursor. Even with a detailed schema, the description should set user expectations about output format and common workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 96%, the baseline is 3. However, the description adds no parameter-specific meaning; it only offers the generic phrase 'using text and filters' which maps vaguely to 'search' and 'filters'. It does not highlight how to use key parameters like cursor for pagination, date ranges, or lineage with categories. The description fails to enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Search' and the resource 'crypto developments' with a qualifier 'recent'. The title 'Search crypto intel' reinforces this. It implicitly distinguishes from sibling 'get_intel' (which likely retrieves a single item) by focusing on search/list behavior. However, it could be more precise about the return type (a list of intel items) and what 'recent' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_intel' (single item retrieval) or other list tools. The description does not mention exclusions or context where this tool is preferred. An agent must infer usage from the name and siblings alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsFind crypto projectsARead-onlyInspect
Find tracked crypto Projects using supported filters.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Comma-separated Project IDs | |
| sort | No | Order by trend (default), creation time, or latest reinforcement | |
| chain | No | Chain to filter by (e.g. "ethereum", "solana") | |
| limit | No | Number of results to return (default and maximum: 50) | |
| names | No | Comma-separated Project names | |
| slugs | No | Comma-separated Project slugs | |
| cursor | No | Cursor returned in meta.nextCursor from the previous page | |
| address | No | Token contract address | |
| tickers | No | Comma-separated tickers | |
| minTrend | No | Minimum current trend measurement | |
| universe | No | Market universe (default: crypto) | |
| xHandles | No | Comma-separated X handles | |
| assetTypes | No | Comma-separated asset types (token, stablecoin, nft-collection) | |
| categories | No | Comma-separated Project category slugs; use get_vocabulary to list them |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe reads. The description adds no behavioral traits beyond stating it uses filters; but with 14 parameters and no mention of pagination, rate limits, or result completeness, the description does not significantly augment the annotation-provided safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded. Every word serves a purpose, but the phrase 'using supported filters' is redundant given the schema already enumerates filter parameters. A slight edge toward clarity could exist.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 14 parameters with 100% schema coverage, a rich output schema, and annotations clearly stating it's read-only and non-destructive, the description captures the core intent. It is adequate for contextual completeness without needing to detail every filter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented in the schema. The description adds no new meaning beyond restating that filters are supported. The baseline of 3 is appropriate since the schema handles the burden fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tracked crypto projects using filters. The verb 'Find' and resource 'tracked crypto Projects' are specific, but the phrase 'using supported filters' is vague and does not distinguish from siblings like 'get_project', which retrieves a single project by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for filtering projects but provides no explicit guidance on when to use this tool versus alternatives like 'get_project' for a single project or other list tools. Without exclusions or when-not-to-use instructions, the agent must infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_topicsList trending topicsBRead-onlyInspect
List the current crypto Topic landscape.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ranking | No | trend for sustained attention | trend |
| projectId | No | Only Topics currently associated with this Project ID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is clearly safe to call. The description adds the time dimension ('current') and the domain ('crypto'), but does not disclose if results are paginated, cached, or if there's any rate limiting. Since annotations cover the key safety info, the description gets a 3 for adding some context without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at just 6 words, with no wasted sentences. It quickly states the tool's action and domain. However, it could be slightly more specific about what 'Topic landscape' entails without sacrificing conciseness (e.g., 'List currently trending crypto topics').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters (0 required), a clear output schema, and read-only annotations, the tool is simple and the description is mostly adequate. The output schema likely handles return values, so no need to describe them. However, the description's vagueness about what 'Topic landscape' means leaves some ambiguity about the scope of results, especially given sibling tools like list_intel that could overlap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented in the schema with names, types, descriptions, and one enum. The description mentions 'current' but does not add any detail about the 'ranking' or 'projectId' parameters beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List the current crypto Topic landscape' clearly identifies the tool's verb (List) and resource (Topic landscape), but it uses the vague phrase 'Topic landscape' which could mean different things. The title says 'trending topics', but the description does not reinforce that the list is specifically trending. Compared to siblings like list_intel and list_projects, this description does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used to see current crypto topics, but there is no guidance on when to use this tool versus siblings like list_intel or get_topic. No exclusions, prerequisites, or contextual alternatives are mentioned. The tool is non-destructive with no required params, so usage seems simple but lacks explicit when-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meCheck AIXBT accessARead-onlyInspect
Check the current credential's access and usage limits.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes |
TDQS
A4.2/5.0
Behavior4/5
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 clear. The description adds behavioral context by specifying that it checks 'access and usage limits,' which details what information the tool returns. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word is meaningful, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with an output schema, the description covers the essential purpose. It might lack nuance about what 'usage limits' entails, but the output schema likely handles that. Given the context signals (no params, has output schema), the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100% (empty schema). The rule states baseline 4 for zero parameters, and the description does not need to add parameter details. It correctly omits any parameter discussion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific language: 'Check the current credential's access and usage limits.' It clearly states what the tool does (check) and what resource it operates on (current credential's access and usage). This distinguishes it from sibling tools like get_intel or list_projects, which retrieve data about other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying one's own permissions or rate limits, but does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or what other tools might serve a similar purpose, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
get_intel1 field changed- changed
Input schema / properties / id / descriptionPrevious value: -"Intel ID"New value: +"Exact Intel item id returned by list_intel, not its project.id"
1 tool update
- Changed
get_report1 field changed- added
Output schema / properties / data / properties / researchAsOfAdded value: +{ + "type": "string" +}
2 tool updates
- Changed
list_intel1 field changed- removed
Input schema / properties / grades / descriptionRemoved value: -"Comma-separated grades: chipped, flawed, cut, polished, flawless"
- Removed
list_reports
7 tool updates
- Changed
get_project2 fields changed- removed
Output schema / properties / data / properties / emergenceRemoved value: -{ - "type": "number" -} - removed
Output schema / properties / data / properties / emergenceRankRemoved value: -{ - "type": "number" -}
- Changed
get_project_series4 fields changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly scores; emergence for retained pre-quarantine six-hour measurements (not breakout probabilities); rank for recorded Trend-rank changes"New value: +"trend for hourly scores; rank for recorded Trend-rank changes" - changed
Input schema / properties / measure / enumPrevious value: -[ - "trend", - "emergence", - "rank" -]New value: +[ + "trend", + "rank" +] - changed
Output schema / properties / data / properties / basis / enumPrevious value: -[ - "hourly", - "six_hourly", - "rank_transitions" -]New value: +[ + "hourly", + "rank_transitions" +] - changed
Output schema / properties / data / properties / measure / enumPrevious value: -[ - "trend", - "emergence", - "rank" -]New value: +[ + "trend", + "rank" +]
- Changed
get_topic1 field changed- removed
Output schema / properties / data / properties / emergenceRemoved value: -{ - "type": "number" -}
- Changed
get_topic_series4 fields changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly scores; emergence for retained pre-quarantine six-hour measurements (not breakout probabilities); rank for recorded Trend-rank changes"New value: +"trend for hourly scores; rank for recorded Trend-rank changes" - changed
Input schema / properties / measure / enumPrevious value: -[ - "trend", - "emergence", - "rank" -]New value: +[ + "trend", + "rank" +] - changed
Output schema / properties / data / properties / basis / enumPrevious value: -[ - "hourly", - "six_hourly", - "rank_transitions" -]New value: +[ + "hourly", + "rank_transitions" +] - changed
Output schema / properties / data / properties / measure / enumPrevious value: -[ - "trend", - "emergence", - "rank" -]New value: +[ + "trend", + "rank" +]
- Changed
list_intel2 fields changed- changed
Input schema / properties / projectRanking / descriptionPrevious value: -"Only return Intel for Projects in the current trend or emergence ranking; emergence currently returns no rows while recalibrating"New value: +"Only return Intel for Projects in the current trend ranking" - changed
Input schema / properties / projectRanking / enumPrevious value: -[ - "trend", - "emergence" -]New value: +[ + "trend" +]
- Changed
list_projects5 fields changed- removed
Input schema / properties / minEmergenceRemoved value: -{ - "description": "Minimum current emergence measurement; currently returns an empty page while recalibrating", - "type": "number" -} - changed
Input schema / properties / sort / descriptionPrevious value: -"Order by trend (default), emergence, creation time, or latest reinforcement; emergence currently returns an empty page while recalibrating"New value: +"Order by trend (default), creation time, or latest reinforcement" - changed
Input schema / properties / sort / enumPrevious value: -[ - "trend", - "emergence", - "createdAt", - "reinforcedAt" -]New value: +[ + "trend", + "createdAt", + "reinforcedAt" +] - removed
Output schema / properties / data / items / properties / emergenceRemoved value: -{ - "type": "number" -} - removed
Output schema / properties / data / items / properties / emergenceRankRemoved value: -{ - "type": "number" -}
- Changed
list_topics3 fields changed- changed
Input schema / properties / ranking / descriptionPrevious value: -"trend for sustained attention; emergence for the currently recalibrating board, which returns empty"New value: +"trend for sustained attention" - changed
Input schema / properties / ranking / enumPrevious value: -[ - "trend", - "emergence" -]New value: +[ + "trend" +] - removed
Output schema / properties / data / items / properties / emergenceRemoved value: -{ - "type": "number" -}
13 tool updates
- Changed
get_intel2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_project2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_project_series2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_report2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_topic2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_topic_series2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_vocabulary2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_clusters2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_intel2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_projects2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_reports2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_topics2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
me2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
2 tool updates
- Changed
get_topic1 field changed- changed
Output schema / properties / data / properties / report / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "publishedAt": { - "type": "string" - }, - "title": { - "type": "string" - } - }, - "required": [ - "id", - "title", - "publishedAt" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "publishedAt": { + "type": "string" + }, + "revisedAt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "title": { + "type": "string" + } + }, + "required": [ + "id", + "title", + "publishedAt", + "revisedAt" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
list_topics1 field changed- changed
Output schema / properties / data / items / properties / report / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "publishedAt": { - "type": "string" - }, - "title": { - "type": "string" - } - }, - "required": [ - "id", - "title", - "publishedAt" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "publishedAt": { + "type": "string" + }, + "revisedAt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "title": { + "type": "string" + } + }, + "required": [ + "id", + "title", + "publishedAt", + "revisedAt" + ], + "type": "object" + }, + { + "type": "null" + } +]
5 tool updates
- Changed
get_project_series1 field changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly scores; emergence for completed six-hour scores; rank for recorded Trend-rank changes"New value: +"trend for hourly scores; emergence for retained pre-quarantine six-hour measurements (not breakout probabilities); rank for recorded Trend-rank changes"
- Changed
get_topic_series1 field changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly scores; emergence for six-hour scores; rank for recorded Trend-rank changes"New value: +"trend for hourly scores; emergence for retained pre-quarantine six-hour measurements (not breakout probabilities); rank for recorded Trend-rank changes"
- Changed
list_intel1 field changed- changed
Input schema / properties / projectRanking / descriptionPrevious value: -"Only return Intel for Projects in the current trend or emergence ranking"New value: +"Only return Intel for Projects in the current trend or emergence ranking; emergence currently returns no rows while recalibrating"
- Changed
list_projects2 fields changed- changed
Input schema / properties / minEmergence / descriptionPrevious value: -"Minimum current emergence measurement"New value: +"Minimum current emergence measurement; currently returns an empty page while recalibrating" - changed
Input schema / properties / sort / descriptionPrevious value: -"Order by trend (default), emergence, creation time, or latest reinforcement"New value: +"Order by trend (default), emergence, creation time, or latest reinforcement; emergence currently returns an empty page while recalibrating"
- Changed
list_topics1 field changed- changed
Input schema / properties / ranking / descriptionPrevious value: -"trend for sustained attention; emergence for an experimental early-attention ranking signal"New value: +"trend for sustained attention; emergence for the currently recalibrating board, which returns empty"
7 tool updates
- Changed
get_project2 fields changed- added
Output schema / properties / data / properties / emergenceAdded value: +{ + "type": "number" +} - added
Output schema / properties / data / properties / emergenceRankAdded value: +{ + "type": "number" +}
- Changed
get_project_series6 fields changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly history; rank for recorded rank changes"New value: +"trend for hourly scores; emergence for completed six-hour scores; rank for recorded Trend-rank changes" - changed
Input schema / properties / measure / enumPrevious value: -[ - "trend", - "rank" -]New value: +[ + "trend", + "emergence", + "rank" +] - changed
Output schema / properties / data / properties / basis / enumPrevious value: -[ - "hourly", - "rank_transitions" -]New value: +[ + "hourly", + "six_hourly", + "rank_transitions" +] - changed
Output schema / properties / data / properties / measure / enumPrevious value: -[ - "trend", - "rank" -]New value: +[ + "trend", + "emergence", + "rank" +] - added
Output schema / properties / meta / properties / versionsAdded value: +{ + "additionalProperties": { + "type": "string" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / meta / requiredAdded value: +[ + "versions" +]
- Changed
get_topic2 fields changed- added
Output schema / properties / data / properties / emergenceAdded value: +{ + "type": "number" +} - changed
Output schema / properties / data / requiredPrevious value: -[ - "id", - "rank", - "name", - "summary", - "trend", - "postCount", - "authorCount", - "lastSeenAt" -]New value: +[ + "id", + "rank", + "name", + "summary", + "postCount", + "authorCount", + "lastSeenAt" +]
- Changed
get_topic_series4 fields changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly history; rank for recorded rank changes"New value: +"trend for hourly scores; emergence for six-hour scores; rank for recorded Trend-rank changes" - changed
Input schema / properties / measure / enumPrevious value: -[ - "trend", - "rank" -]New value: +[ + "trend", + "emergence", + "rank" +] - changed
Output schema / properties / data / properties / basis / enumPrevious value: -[ - "hourly", - "rank_transitions" -]New value: +[ + "hourly", + "six_hourly", + "rank_transitions" +] - changed
Output schema / properties / data / properties / measure / enumPrevious value: -[ - "trend", - "rank" -]New value: +[ + "trend", + "emergence", + "rank" +]
- Changed
list_intel2 fields changed- changed
Input schema / properties / projectRanking / descriptionPrevious value: -"Only return Intel for Projects in the current trend ranking"New value: +"Only return Intel for Projects in the current trend or emergence ranking" - changed
Input schema / properties / projectRanking / enumPrevious value: -[ - "trend" -]New value: +[ + "trend", + "emergence" +]
- Changed
list_projects5 fields changed- added
Input schema / properties / minEmergenceAdded value: +{ + "description": "Minimum current emergence measurement", + "type": "number" +} - changed
Input schema / properties / sort / descriptionPrevious value: -"Order by trend (default), creation time, or latest reinforcement"New value: +"Order by trend (default), emergence, creation time, or latest reinforcement" - changed
Input schema / properties / sort / enumPrevious value: -[ - "trend", - "createdAt", - "reinforcedAt" -]New value: +[ + "trend", + "emergence", + "createdAt", + "reinforcedAt" +] - added
Output schema / properties / data / items / properties / emergenceAdded value: +{ + "type": "number" +} - added
Output schema / properties / data / items / properties / emergenceRankAdded value: +{ + "type": "number" +}
- Changed
list_topics3 fields changed- added
Input schema / properties / rankingAdded value: +{ + "default": "trend", + "description": "trend for sustained attention; emergence for an experimental early-attention ranking signal", + "enum": [ + "trend", + "emergence" + ], + "type": "string" +} - added
Output schema / properties / data / items / properties / emergenceAdded value: +{ + "type": "number" +} - changed
Output schema / properties / data / items / requiredPrevious value: -[ - "id", - "rank", - "name", - "summary", - "trend", - "postCount", - "authorCount", - "lastSeenAt" -]New value: +[ + "id", + "rank", + "name", + "summary", + "postCount", + "authorCount", + "lastSeenAt" +]
1 tool update
- Changed
list_projects4 fields changed- removed
Input schema / properties / hasTokenRemoved value: -{ - "description": "Only include Projects with (true) or without (false) a token", - "type": "boolean" -} - changed
Input schema / properties / minTrend / descriptionPrevious value: -"Minimum current trend score from 0 to 100"New value: +"Minimum current trend measurement" - removed
Input schema / properties / minTrend / maximumRemoved value: -100 - removed
Input schema / properties / minTrend / minimumRemoved value: -0
1 tool update
- Removed
chat_with_aixbt
1 tool update
- Changed
list_intel2 fields changed- changed
Input schema / properties / sort / descriptionPrevious value: -"Order by latest content change (lastEvolvedAt, default), latest reinforcement, or first detection"New value: +"Order by first detection (default) or latest reinforcement" - changed
Input schema / properties / sort / enumPrevious value: -[ - "lastEvolvedAt", - "reinforcedAt", - "detectedAt" -]New value: +[ + "reinforcedAt", + "detectedAt" +]
2 tool updates
- Changed
get_intel5 fields changed- added
Output schema / properties / data / properties / activity / items / additionalPropertiesAdded value: +false - removed
Output schema / properties / data / properties / activity / items / oneOfRemoved value: -[ - { - "additionalProperties": false, - "properties": { - "action": { - "const": "follow", - "type": "string" - }, - "clusters": { - "items": { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - "type": "array" - }, - "detectedAt": { - "type": "string" - }, - "eventTime": { - "additionalProperties": false, - "properties": { - "reason": { - "const": "not_stated", - "type": "string" - }, - "status": { - "const": "unknown", - "type": "string" - } - }, - "required": [ - "status", - "reason" - ], - "type": "object" - }, - "headline": { - "type": "string" - }, - "occurredAt": { - "type": "string" - } - }, - "required": [ - "detectedAt", - "occurredAt", - "action", - "eventTime" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "enum": [ - "observation", - "official_statement", - "correction", - "merge" - ], - "type": "string" - }, - "clusters": { - "items": { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - "type": "array" - }, - "detectedAt": { - "type": "string" - }, - "eventTime": { - "oneOf": [ - { - "additionalProperties": false, - "properties": { - "at": { - "type": "string" - }, - "precision": { - "enum": [ - "instant", - "day", - "week", - "month" - ], - "type": "string" - }, - "relationToSource": { - "enum": [ - "current", - "historical", - "future" - ], - "type": "string" - }, - "status": { - "const": "instant", - "type": "string" - } - }, - "required": [ - "status", - "at", - "precision", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "endAt": { - "type": "string" - }, - "precision": { - "enum": [ - "day", - "week", - "month" - ], - "type": "string" - }, - "relationToSource": { - "enum": [ - "current", - "historical", - "future" - ], - "type": "string" - }, - "startAt": { - "type": "string" - }, - "status": { - "const": "interval", - "type": "string" - } - }, - "required": [ - "status", - "startAt", - "endAt", - "precision", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "relationToSource": { - "enum": [ - "before_post", - "after_post", - "around_post" - ], - "type": "string" - }, - "status": { - "const": "relative_unresolved", - "type": "string" - } - }, - "required": [ - "status", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "reason": { - "enum": [ - "not_stated", - "ambiguous", - "ongoing" - ], - "type": "string" - }, - "status": { - "const": "unknown", - "type": "string" - } - }, - "required": [ - "status", - "reason" - ], - "type": "object" - } - ] - }, - "headline": { - "type": "string" - }, - "occurredAt": { - "type": "string" - }, - "sentiment": { - "additionalProperties": false, - "properties": { - "value": { - "enum": [ - "positive", - "neutral", - "negative" - ], - "type": "string" - } - }, - "required": [ - "value" - ], - "type": "object" - }, - "source": { - "additionalProperties": false, - "properties": { - "official": { - "type": "boolean" - }, - "url": { - "type": "string" - } - }, - "required": [ - "url", - "official" - ], - "type": "object" - } - }, - "required": [ - "detectedAt", - "occurredAt", - "action" - ], - "type": "object" - } -] - added
Output schema / properties / data / properties / activity / items / propertiesAdded value: +{ + "action": { + "enum": [ + "observation", + "official_statement", + "correction", + "merge" + ], + "type": "string" + }, + "clusters": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "detectedAt": { + "type": "string" + }, + "eventTime": { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "at": { + "type": "string" + }, + "precision": { + "enum": [ + "instant", + "day", + "week", + "month" + ], + "type": "string" + }, + "relationToSource": { + "enum": [ + "current", + "historical", + "future" + ], + "type": "string" + }, + "status": { + "const": "instant", + "type": "string" + } + }, + "required": [ + "status", + "at", + "precision", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "endAt": { + "type": "string" + }, + "precision": { + "enum": [ + "day", + "week", + "month" + ], + "type": "string" + }, + "relationToSource": { + "enum": [ + "current", + "historical", + "future" + ], + "type": "string" + }, + "startAt": { + "type": "string" + }, + "status": { + "const": "interval", + "type": "string" + } + }, + "required": [ + "status", + "startAt", + "endAt", + "precision", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "relationToSource": { + "enum": [ + "before_post", + "after_post", + "around_post" + ], + "type": "string" + }, + "status": { + "const": "relative_unresolved", + "type": "string" + } + }, + "required": [ + "status", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "reason": { + "enum": [ + "not_stated", + "ambiguous", + "ongoing" + ], + "type": "string" + }, + "status": { + "const": "unknown", + "type": "string" + } + }, + "required": [ + "status", + "reason" + ], + "type": "object" + } + ] + }, + "headline": { + "type": "string" + }, + "occurredAt": { + "type": "string" + }, + "sentiment": { + "additionalProperties": false, + "properties": { + "value": { + "enum": [ + "positive", + "neutral", + "negative" + ], + "type": "string" + } + }, + "required": [ + "value" + ], + "type": "object" + }, + "source": { + "additionalProperties": false, + "properties": { + "official": { + "type": "boolean" + }, + "url": { + "type": "string" + } + }, + "required": [ + "url", + "official" + ], + "type": "object" + } +} - added
Output schema / properties / data / properties / activity / items / requiredAdded value: +[ + "action", + "detectedAt", + "occurredAt" +] - added
Output schema / properties / data / properties / activity / items / typeAdded value: +"object"
- Changed
list_intel5 fields changed- added
Output schema / properties / data / items / properties / activity / items / additionalPropertiesAdded value: +false - removed
Output schema / properties / data / items / properties / activity / items / oneOfRemoved value: -[ - { - "additionalProperties": false, - "properties": { - "action": { - "const": "follow", - "type": "string" - }, - "clusters": { - "items": { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - "type": "array" - }, - "detectedAt": { - "type": "string" - }, - "eventTime": { - "additionalProperties": false, - "properties": { - "reason": { - "const": "not_stated", - "type": "string" - }, - "status": { - "const": "unknown", - "type": "string" - } - }, - "required": [ - "status", - "reason" - ], - "type": "object" - }, - "headline": { - "type": "string" - }, - "occurredAt": { - "type": "string" - } - }, - "required": [ - "detectedAt", - "occurredAt", - "action", - "eventTime" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "enum": [ - "observation", - "official_statement", - "correction", - "merge" - ], - "type": "string" - }, - "clusters": { - "items": { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - "type": "array" - }, - "detectedAt": { - "type": "string" - }, - "eventTime": { - "oneOf": [ - { - "additionalProperties": false, - "properties": { - "at": { - "type": "string" - }, - "precision": { - "enum": [ - "instant", - "day", - "week", - "month" - ], - "type": "string" - }, - "relationToSource": { - "enum": [ - "current", - "historical", - "future" - ], - "type": "string" - }, - "status": { - "const": "instant", - "type": "string" - } - }, - "required": [ - "status", - "at", - "precision", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "endAt": { - "type": "string" - }, - "precision": { - "enum": [ - "day", - "week", - "month" - ], - "type": "string" - }, - "relationToSource": { - "enum": [ - "current", - "historical", - "future" - ], - "type": "string" - }, - "startAt": { - "type": "string" - }, - "status": { - "const": "interval", - "type": "string" - } - }, - "required": [ - "status", - "startAt", - "endAt", - "precision", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "relationToSource": { - "enum": [ - "before_post", - "after_post", - "around_post" - ], - "type": "string" - }, - "status": { - "const": "relative_unresolved", - "type": "string" - } - }, - "required": [ - "status", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "reason": { - "enum": [ - "not_stated", - "ambiguous", - "ongoing" - ], - "type": "string" - }, - "status": { - "const": "unknown", - "type": "string" - } - }, - "required": [ - "status", - "reason" - ], - "type": "object" - } - ] - }, - "headline": { - "type": "string" - }, - "occurredAt": { - "type": "string" - }, - "sentiment": { - "additionalProperties": false, - "properties": { - "value": { - "enum": [ - "positive", - "neutral", - "negative" - ], - "type": "string" - } - }, - "required": [ - "value" - ], - "type": "object" - }, - "source": { - "additionalProperties": false, - "properties": { - "official": { - "type": "boolean" - }, - "url": { - "type": "string" - } - }, - "required": [ - "url", - "official" - ], - "type": "object" - } - }, - "required": [ - "detectedAt", - "occurredAt", - "action" - ], - "type": "object" - } -] - added
Output schema / properties / data / items / properties / activity / items / propertiesAdded value: +{ + "action": { + "enum": [ + "observation", + "official_statement", + "correction", + "merge" + ], + "type": "string" + }, + "clusters": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "detectedAt": { + "type": "string" + }, + "eventTime": { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "at": { + "type": "string" + }, + "precision": { + "enum": [ + "instant", + "day", + "week", + "month" + ], + "type": "string" + }, + "relationToSource": { + "enum": [ + "current", + "historical", + "future" + ], + "type": "string" + }, + "status": { + "const": "instant", + "type": "string" + } + }, + "required": [ + "status", + "at", + "precision", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "endAt": { + "type": "string" + }, + "precision": { + "enum": [ + "day", + "week", + "month" + ], + "type": "string" + }, + "relationToSource": { + "enum": [ + "current", + "historical", + "future" + ], + "type": "string" + }, + "startAt": { + "type": "string" + }, + "status": { + "const": "interval", + "type": "string" + } + }, + "required": [ + "status", + "startAt", + "endAt", + "precision", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "relationToSource": { + "enum": [ + "before_post", + "after_post", + "around_post" + ], + "type": "string" + }, + "status": { + "const": "relative_unresolved", + "type": "string" + } + }, + "required": [ + "status", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "reason": { + "enum": [ + "not_stated", + "ambiguous", + "ongoing" + ], + "type": "string" + }, + "status": { + "const": "unknown", + "type": "string" + } + }, + "required": [ + "status", + "reason" + ], + "type": "object" + } + ] + }, + "headline": { + "type": "string" + }, + "occurredAt": { + "type": "string" + }, + "sentiment": { + "additionalProperties": false, + "properties": { + "value": { + "enum": [ + "positive", + "neutral", + "negative" + ], + "type": "string" + } + }, + "required": [ + "value" + ], + "type": "object" + }, + "source": { + "additionalProperties": false, + "properties": { + "official": { + "type": "boolean" + }, + "url": { + "type": "string" + } + }, + "required": [ + "url", + "official" + ], + "type": "object" + } +} - added
Output schema / properties / data / items / properties / activity / items / requiredAdded value: +[ + "action", + "detectedAt", + "occurredAt" +] - added
Output schema / properties / data / items / properties / activity / items / typeAdded value: +"object"
12 tool updates
- Changed
chat_with_aixbt1 field changed- changed
Input schema / properties / messages / descriptionPrevious value: -"Conversation history for Indigo (1-50 messages). First message is typically the user question."New value: +"Conversation turns to send, oldest first (1-50). Include prior turns for follow-up questions."
- Changed
get_intel2 fields changed- added
Input schema / properties / activity / descriptionAdded value: +"Activity rows to include: all (default), source observations only, or none" - changed
Input schema / properties / id / descriptionPrevious value: -"Intel id"New value: +"Intel ID"
- Changed
get_project1 field changed- changed
Input schema / properties / idOrSlug / descriptionPrevious value: -"Canonical Project id or slug"New value: +"Project ID or slug; slug aliases resolve"
- Changed
get_project_series4 fields changed- changed
Input schema / properties / from / descriptionPrevious value: -"Window start (ISO 8601)"New value: +"Start of time window (ISO 8601)" - changed
Input schema / properties / idOrSlug / descriptionPrevious value: -"Canonical Project id or slug"New value: +"Project ID or slug; slug aliases resolve" - changed
Input schema / properties / measure / descriptionPrevious value: -"Measurement series"New value: +"trend for hourly history; rank for recorded rank changes" - changed
Input schema / properties / to / descriptionPrevious value: -"Window end (ISO 8601)"New value: +"End of time window (ISO 8601)"
- Changed
get_report1 field changed- changed
Input schema / properties / id / descriptionPrevious value: -"Report id"New value: +"Report ID"
- Changed
get_topic1 field changed- changed
Input schema / properties / topicId / descriptionPrevious value: -"Topic id from list_topics"New value: +"Topic ID from list_topics"
- Changed
get_topic_series4 fields changed- changed
Input schema / properties / from / descriptionPrevious value: -"Window start (ISO 8601)"New value: +"Start of time window (ISO 8601)" - changed
Input schema / properties / measure / descriptionPrevious value: -"Measurement series"New value: +"trend for hourly history; rank for recorded rank changes" - changed
Input schema / properties / to / descriptionPrevious value: -"Window end (ISO 8601)"New value: +"End of time window (ISO 8601)" - changed
Input schema / properties / topicId / descriptionPrevious value: -"Known Topic id"New value: +"Topic ID"
- Changed
list_clusters1 field changed- added
Input schema / properties / universe / descriptionAdded value: +"Market universe (default: crypto)"
- Changed
list_intel21 fields changed- changed
Input schema / properties / activity / descriptionPrevious value: -"Evidence trail mode: all (default), observations, or none"New value: +"Activity rows to include: all (default), source observations only, or none" - changed
Input schema / properties / assetTypes / descriptionPrevious value: -"Comma-separated asset types (live reads only)"New value: +"Comma-separated asset types; use get_vocabulary to list them" - changed
Input schema / properties / categories / descriptionPrevious value: -"Comma-separated intel categories (discover via get_vocabulary)"New value: +"Comma-separated Intel category names; use get_vocabulary and choose intelCategories[].name" - changed
Input schema / properties / clusterIds / descriptionPrevious value: -"Comma-separated cluster ids"New value: +"Comma-separated cluster IDs" - changed
Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from a previous page (meta.nextCursor)"New value: +"Cursor returned in meta.nextCursor from the previous page" - changed
Input schema / properties / detectedAfter / descriptionPrevious value: -"ISO 8601 lower bound"New value: +"Detected at or after this time (ISO 8601)" - changed
Input schema / properties / detectedBefore / descriptionPrevious value: -"ISO 8601 upper bound"New value: +"Detected at or before this time (ISO 8601)" - added
Input schema / properties / hasOfficialSource / descriptionAdded value: +"Set true to return only Intel with an official Project source" - added
Input schema / properties / limit / descriptionAdded value: +"Results per page (default and maximum: 50)" - added
Input schema / properties / minClusters / descriptionAdded value: +"Minimum number of community clusters represented" - changed
Input schema / properties / projectIds / descriptionPrevious value: -"Comma-separated Project ids"New value: +"Comma-separated Project IDs" - changed
Input schema / properties / projectRanking / descriptionPrevious value: -"Restrict to currently ranked Projects"New value: +"Only return Intel for Projects in the current trend ranking" - changed
Input schema / properties / reinforcedAfter / descriptionPrevious value: -"ISO 8601 lower bound"New value: +"Reinforced at or after this time (ISO 8601)" - changed
Input schema / properties / reinforcedBefore / descriptionPrevious value: -"ISO 8601 upper bound"New value: +"Reinforced at or before this time (ISO 8601)" - changed
Input schema / properties / search / descriptionPrevious value: -"Free-text deep search; combines with every other filter"New value: +"Any text to match across Project identity and Intel content; combines with all filters" - removed
Input schema / properties / search / maxLengthRemoved value: -200 - removed
Input schema / properties / search / minLengthRemoved value: -2 - changed
Input schema / properties / sort / descriptionPrevious value: -"Sort field (default: lastEvolvedAt)"New value: +"Order by latest content change (lastEvolvedAt, default), latest reinforcement, or first detection" - added
Output schema / properties / meta / properties / executedSearchAdded value: +{ + "description": "Normalized terms attempted within a bounded search", + "type": "string" +} - added
Output schema / properties / meta / properties / searchCoverageAdded value: +{ + "description": "Present when responsiveness bounds may omit matching results", + "enum": [ + "bounded_candidates", + "bounded_recent", + "bounded_candidates_recent" + ], + "type": "string" +} - added
Output schema / properties / meta / properties / searchQueryAdded value: +{ + "description": "Normalized query requested by the caller", + "type": "string" +}
- Changed
list_projects8 fields changed- changed
Input schema / properties / categories / descriptionPrevious value: -"Comma-separated canonical category slugs"New value: +"Comma-separated Project category slugs; use get_vocabulary to list them" - changed
Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from a previous page (meta.nextCursor)"New value: +"Cursor returned in meta.nextCursor from the previous page" - added
Input schema / properties / hasToken / descriptionAdded value: +"Only include Projects with (true) or without (false) a token" - changed
Input schema / properties / ids / descriptionPrevious value: -"Comma-separated Project ids"New value: +"Comma-separated Project IDs" - changed
Input schema / properties / limit / descriptionPrevious value: -"Results per page (default: 50, max: 50)"New value: +"Number of results to return (default and maximum: 50)" - changed
Input schema / properties / minTrend / descriptionPrevious value: -"Minimum canonical trend measurement"New value: +"Minimum current trend score from 0 to 100" - changed
Input schema / properties / sort / descriptionPrevious value: -"Sort field (default: trend)"New value: +"Order by trend (default), creation time, or latest reinforcement" - added
Input schema / properties / universe / descriptionAdded value: +"Market universe (default: crypto)"
- Changed
list_reports5 fields changed- changed
Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from a previous page (meta.nextCursor)"New value: +"Cursor returned in meta.nextCursor from the previous page" - added
Input schema / properties / limit / descriptionAdded value: +"Results per page (default and maximum: 50)" - added
Input schema / properties / projectId / descriptionAdded value: +"Only reports for this Project ID" - added
Input schema / properties / projectSlug / descriptionAdded value: +"Only reports for this Project slug" - added
Input schema / properties / topicId / descriptionAdded value: +"Only reports for this Topic ID"
- Changed
list_topics1 field changed- changed
Input schema / properties / projectId / descriptionPrevious value: -"Project id: serve the Topics associated with it"New value: +"Only Topics currently associated with this Project ID"
14 tool updates
- First observed
chat_with_aixbt - First observed
get_intel - First observed
get_project - First observed
get_project_series - First observed
get_report - First observed
get_topic - First observed
get_topic_series - First observed
get_vocabulary - First observed
list_clusters - First observed
list_intel - First observed
list_projects - First observed
list_reports - First observed
list_topics - First observed
me
Related MCP Connectors
Crypto market intelligence: social sentiment, on-chain, trending narratives & analyst insights.
Crypto market intelligence: regime detection, funding rates, liquidations, prices, signals.
Crypto fundamental analysis, sentiment and whale tracking for traders and AI agents.
Real-time digital asset narrative intelligence from 1,000+ curated media sources.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides predictive crypto market intelligence synthesized from whale positions, developer activity, and behavioral demand signals. Enables convergence scoring, whale divergence detection, and risk radar through MCP tools.66 npmMIT
- AlicenseNot gradedqualityCmaintenanceDelivers real-time crypto market microstructure, derivatives, order flow CVD/OI regime classification, fear & greed sentiment, and whale tracking context, enabling traders to assess market regimes and complement charting tools.28 npmMIT
- AlicenseAqualityAmaintenancePre-computed financial market intelligence for AI agents. Stocks, crypto, and ETFs.9114 npm5MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.