Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fiware-orion-mcp Show me all Camera entities that are offline"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for FIWARE Orion Context Broker. Enables LLMs like Claude to manage NGSI-v2 context entities — IoT devices, cameras, sensors, vehicles, and any real-world object modeled as a digital twin.
No official FIWARE MCP exists yet. This is the first one.
FIWARE is an open standard (ETSI NGSI-LD) for Smart City and IoT data management. The Orion Context Broker is its core component — it stores the current state of all entities and notifies subscribers when things change.
Related MCP server: aas-mcp
Tool | Description |
| Verify Orion connectivity and version |
| List all entity types and their attributes |
| Query entities by type, pattern, filter, geo |
| Get full details of a specific entity |
| Create a new NGSI entity |
| Update entity attributes |
| Delete an entity |
| Subscribe to attribute change notifications |
| List active subscriptions |
| Get time-series history for an entity |
| Get aggregated history across entity type |
cd docker
docker compose up -d
# Verify:
curl http://localhost:1026/version
curl http://localhost:8668/versionpip install fiware-orion-mcp
# or from source:
pip install -e .Add to your ~/.claude/mcp.json or project MCP config:
{
"mcpServers": {
"fiware-orion": {
"command": "python",
"args": ["-m", "fiware_mcp.server"],
"env": {
"ORION_URL": "http://your-orion-host:1026",
"QUANTUMLEAP_URL": "http://your-ql-host:8668"
}
}
}
}Variable | Default | Description |
|
| Orion Context Broker URL |
|
| QuantumLeap URL |
| (empty) | Multi-tenancy service name |
|
| Multi-tenancy service path |
> List all entity types in the Context Broker
> Show me all Camera entities that are offline
> Get the full details of Camera:TIMONE-01
> Update Camera:TIMONE-01 status to "maintenance"
> Show me the uptime history of Camera:TIMONE-01 for the last 7 daysNGSI-LD support (Orion-LD)
Batch operations
Geo-query helpers (find entities near a point)
Export entities as GeoJSON
MIT — contributions welcome.
Create a new entity in the Context Broker.
Args: entity_id: Unique entity ID (e.g. 'Camera:CAM-001'). Convention: 'Type:Name'. entity_type: Entity type (e.g. 'Camera', 'TrafficSensor', 'ParkingSpot'). attributes: Dict of attribute definitions. Each attribute: {"attr_name": {"type": "Text|Number|Boolean|geo:json|DateTime", "value": }} Example: {"status": {"type": "Text", "value": "online"}, "temperature": {"type": "Number", "value": 22.5}}
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ||
| entity_type | Yes | ||
| attributes | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not destructive, and not idempotent. The description adds that it creates an entity, but does not disclose potential side effects, auth needs, or rate limits. With annotations present, this is adequate 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 clear and well-structured as a docstring, with each argument explained. Slightly verbose but each sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. The description explains all three required parameters and nested structures sufficiently. Sibling tools list provides context, but the description itself is complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries full burden. It provides detailed semantics: entity_id convention ('Type:Name'), entity_type examples, and a complete structure for attributes with types and example values, far exceeding minimal schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new entity in a Context Broker, using a specific verb and resource. It differentiates from siblings like orion_delete_entity and orion_get_entity by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage hints through conventions (entity_id format, attribute examples) but does not explicitly state when to use this tool over alternatives 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.
Create a subscription to receive notifications when entities change.
Args: entity_type: Entity type to watch (e.g. 'Camera'). watched_attrs: List of attribute names that trigger notification. notification_url: HTTP endpoint to receive POST notifications. id_pattern: Optional regex to filter by entity ID. description: Human-readable description.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | Yes | ||
| watched_attrs | Yes | ||
| notification_url | Yes | ||
| id_pattern | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly and non-destructive. Description adds that it is a creation action but does not disclose further behavioral aspects like subscription lifetime, rate limits, or side effects.
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, uses a clear structure with an Args section listing parameters, and wastes no words. It is front-loaded with the action.
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?
Covers main purpose and parameters but lacks details about output (though output schema exists), error handling, or post-creation behavior. Adequate for a simple tool but could be more complete.
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?
With 0% schema coverage, the description provides meaningful descriptions for all five parameters: entity_type, watched_attrs, notification_url, id_pattern, and description. This adds value beyond the bare 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 it creates a subscription for entity change notifications, with specific parameters. This distinguishes it from sibling tools like orion_create_entity or orion_list_subscriptions.
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 usage for receiving notifications but does not explicitly state when not to use it or compare to alternatives. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an entity from the Context Broker.
Args: entity_id: Entity ID to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds minimal behavioral context (only 'from the Context Broker'), not contradicting annotations but also not enriching 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 concise, with two lines—one for purpose and one for the parameter. It is front-loaded and contains no unnecessary information, though the parameter line could be integrated.
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 tool's simplicity (one parameter, annotations, and an output schema), the description is adequate. It covers the core action and parameter, though it could mention return behavior or idempotency implications.
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 0%, and the description provides a brief explanation 'Entity ID to delete' for the only parameter. This adds meaning beyond the schema's type-only definition but remains minimal.
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 'Delete an entity from the Context Broker,' providing a specific verb (delete) and resource (entity). It effectively distinguishes from sibling tools like orion_create_entity and orion_get_entity.
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 offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, 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.
Get full details of a specific entity by its ID.
Args: entity_id: Entity ID (e.g. 'Camera:TIMONE-01'). attrs: Optional comma-separated list of attributes to return.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ||
| attrs | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a read-only operation. The description adds 'Get full details' but no further behavioral context (e.g., no mention of error handling, permissions, or side effects). For a simple read-only get, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The Args section is clear but slightly redundant with parameter names. Overall, it is efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (get by ID) and the presence of an output schema (not shown but known), the description covers the essential behavior. Sibling tools provide context for other operations. No major gaps identified.
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 0%, so the description compensates by explaining both parameters: entity_id as 'Entity ID (e.g. 'Camera:TIMONE-01')' and attrs as 'Optional comma-separated list of attributes to return'. This adds significant meaning beyond the bare input 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 'Get full details of a specific entity by its ID', which specifies a verb (get) and a resource (entity details by ID). It distinguishes from sibling tools like orion_query_entities (multiple entities) and orion_delete_entity (delete operation).
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 on when to use this tool vs alternatives like orion_query_entities. The description implies use for a single entity by ID, but does not mention exclusions or provide alternative tool names for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Orion Context Broker version and uptime. Use to verify connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so behavior is transparent. Description adds 'Use to verify connectivity' which aligns. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly one sentence plus a usage tip. Zero wasted words, efficiently communicates purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, annotations covering readOnly, and existence of output schema, the description is fully sufficient. All necessary information 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?
No parameters, so description doesn't need to add param info. Schema coverage is 100%. Baseline for 0 params is 4, and description handles it appropriately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get Orion Context Broker version and uptime', a specific verb and resource. It distinguishes from siblings like orion_create_entity or orion_get_entity which deal with entities, not version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to verify connectivity', which guides when to use. No alternatives needed as no other tool provides version info. Missing explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active subscriptions in the Context Broker. Subscriptions trigger HTTP notifications when entity attributes change.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's disclosure of 'list' is redundant. The added detail about notifications provides some behavioral context, but lacks further traits like pagination or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: the first states the core purpose, the second provides relevant behavioral context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the existence of an output schema, the description adequately covers the tool's purpose. Could mention default fields or limits, but not necessary for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to explain parameter semantics. The baseline score for 0 parameters is 4.
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 'List all active subscriptions' with a specific verb and resource, and adds meaningful context about subscriptions triggering notifications. It distinguishes from sibling tools like orion_create_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all entity types registered in the Context Broker. Returns type names and attribute counts. Use this first to understand the data model.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by detailing that it returns type names and attribute counts. No contradictions; behavior is fully disclosed for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and essential detail, second provides usage guidance. No fluff, every sentence 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?
Complete for a parameter-less list tool with an output schema. Description covers return content (type names, attribute counts) and usage context, sufficient for agent 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?
No parameters exist (0 params, 100% schema coverage). Baseline 4 applies as there is nothing to describe beyond the schema, and the description adds context about return content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all entity types registered in the Context Broker, specifying the return includes type names and attribute counts. This distinct purpose differentiates it from sibling tools that create, get, or query entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool first to understand the data model, providing clear timing guidance. It does not cover when not to use or list alternatives, but this is a simple discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query entities from the Context Broker.
Args: entity_type: Filter by type (e.g. 'Camera', 'TrafficSensor'). id_pattern: Regex pattern on entity ID (e.g. 'Camera:TIMONE.*'). q: Simple Query Language filter (e.g. 'status==online', 'temperature>25'). attrs: Comma-separated list of attributes to return (e.g. 'status,location'). limit: Max results (default 20, max 1000). offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | No | ||
| id_pattern | No | ||
| q | No | ||
| attrs | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details query behavior including filters (type, ID pattern, simple query language), attribute selection, pagination with defaults (limit 20, max 1000, offset 0). This goes well beyond the readOnlyHint annotation, fully informing the agent of operational traits.
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 well-structured with an 'Args:' list, but the bullet points could be more concise. However, each sentence adds value and the format is clear and scannable.
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 6 parameters, none required, and an output schema present, the description covers all needed details: filters, pagination, defaults, and parameter constraints. No essential information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all 6 parameters with examples and defaults (e.g., 'Camera:TIMONE.*', 'status==online'), adding significant meaning beyond the input schema. Each parameter's role and usage are clearly defined.
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 'Query entities from the Context Broker', using a specific verb and resource. It distinguishes itself from sibling tools like orion_create_entity and orion_get_entity by focusing on querying multiple entities with filters.
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 explains parameters and filtering options but does not explicitly state when to use this tool versus alternatives like orion_get_entity for a single entity. Usage context is implied but not formally clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update one or more attributes of an existing entity.
Args: entity_id: Entity ID to update. attributes: Dict of attributes to update. Example: {"status": {"type": "Text", "value": "offline"}, "snmp_uptime": {"type": "Number", "value": 3600}}
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ||
| attributes | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and non-destructive, so the description adds minimal behavioral context beyond stating 'update'. It does not elaborate on side effects, authorization needs, or behavior when updating partial attributes.
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?
Description is concise and front-loaded with purpose. The docstring-style listing of arguments is efficient, though slightly verbose with 'Args:' prefix. No wasted sentences.
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 presence of output schema (implied), return values are covered. However, the description misses important details like validation rules, error conditions, or the fact that attributes parameter uses additionalProperties (any key allowed). The tool is simple but could benefit from a note about not removing unspecified attributes.
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?
With 0% schema description coverage, the description compensates by explaining the attributes parameter with a concrete example showing the nested structure. The entity_id is self-explanatory. This adds meaningful context 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?
Description clearly states 'update one or more attributes of an existing entity' providing a specific verb and resource. It distinguishes from sibling tools like create and delete by focusing on attribute mutation.
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?
Description implies usage for updating attributes on an existing entity but lacks explicit guidance on when to use this tool versus alternatives like orion_create_entity or orion_get_entity. No exclusion criteria or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical time-series data for an entity from QuantumLeap.
Args: entity_id: Entity ID (e.g. 'Camera:TIMONE-01'). entity_type: Entity type for disambiguation. attr: Specific attribute to retrieve (e.g. 'temperature'). All attrs if omitted. from_date: ISO8601 start date (e.g. '2026-03-01T00:00:00'). to_date: ISO8601 end date (e.g. '2026-03-07T23:59:59'). limit: Max data points (default 100). aggr_method: Aggregation: 'count', 'sum', 'avg', 'min', 'max'. aggr_period: Aggregation period: 'year', 'month', 'day', 'hour', 'minute', 'second'.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ||
| entity_type | No | ||
| attr | No | ||
| from_date | No | ||
| to_date | No | ||
| limit | No | ||
| aggr_method | No | ||
| aggr_period | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description is consistent with readOnlyHint annotation. It discloses that the tool retrieves historical data but does not add behavioral details beyond that (e.g., rate limits, data source specifics). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with a clear first sentence and parameter list. Some verbosity in parameter examples, but overall efficient. The structure is easy to parse.
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?
Covers input parameters thoroughly and output is handled by output schema. Lacks usage context (when/why to use this vs alternatives) but otherwise complete for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides detailed parameter docs with examples (entity ID format, ISO8601 dates, default limit, aggregation options). This adds significant meaning beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get historical time-series data for an entity from QuantumLeap' – a specific verb+resource. It distinguishes from sibling 'quantumleap_get_type_history' by specifying 'for an entity'.
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 vs alternatives (e.g., quantumleap_get_type_history, Orion query tools). No explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated historical data for ALL entities of a given type. Useful for fleet-level analytics (e.g. average temperature across all sensors).
Args: entity_type: Entity type (e.g. 'Camera'). attr: Attribute to aggregate (e.g. 'snmp_uptime'). from_date: ISO8601 start date. to_date: ISO8601 end date. limit: Max data points. aggr_method: 'count', 'sum', 'avg', 'min', 'max'. aggr_period: 'year', 'month', 'day', 'hour', 'minute', 'second'.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | Yes | ||
| attr | Yes | ||
| from_date | No | ||
| to_date | No | ||
| limit | No | ||
| aggr_method | No | ||
| aggr_period | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context by specifying that the tool returns aggregated historical data. No contradictions exist. The description provides behavioral context beyond what annotations offer, such as the aggregation method and period.
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 structured with a clear purpose and an Args section. It is informative but could be slightly more concise; however, it earns its place with useful details and remains readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (not shown but indicated), the description does not need to explain return values. It covers the input parameters well and provides usage context. Minor gaps like missing edge case handling exist, but overall it is complete for most use cases.
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?
Despite 0% schema description coverage, the description includes a detailed Args section with examples for each parameter (e.g., 'entity_type: Entity type (e.g. Camera)', 'attr: Attribute to aggregate (e.g. snmp_uptime)'). This adds significant meaning beyond the schema's types and defaults, fully compensating for the schema gap.
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 'Get aggregated historical data for ALL entities of a given type.' It uses a specific verb ('Get') and resource ('aggregated historical data for all entities of a type'), and clearly differentiates from sibling tools like quantumleap_get_history which targets a single entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Useful for fleet-level analytics' and provides an example, giving clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives beyond the implied differentiation from the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0orion_create_entityorion_create_subscriptionorion_delete_entityorion_get_entityorion_get_versionorion_list_subscriptionsorion_list_typesorion_query_entitiesorion_update_attributesquantumleap_get_historyquantumleap_get_type_historyAll 11 tools have clearly distinct purposes, with no overlap. Each tool targets a specific operation (create, read, update, delete, list, query) on distinct resources (entities, subscriptions, types, history).
All tool names follow a consistent snake_case verb_noun pattern with clear domain prefixes (orion_ and quantumleap_), ensuring easy readability and predictable naming.
11 tools is well-scoped for a Context Broker with historical data integration, covering essential CRUD, query, subscription, and history operations without unnecessary bloat.
The tool set covers core entity CRUD and queries, but lacks update and delete operations for subscriptions, which is a notable gap that may cause agent failures in subscription lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/k2iser/fiware-orion-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
