Agentery

Get provider profile

get_provider_profile

Read-only

Use to check one specific listing before recommending or connecting it: plans and prices with billing units, what it does, integrations, deployment (hosted / self_hosted / both / unknown, with evidence), licence (named licence only), liveness and how to connect (website, docs, MCP endpoint with a copy-paste config_snippet, A2A agent card, API, install). Fields are null when the vendor publishes nothing; nothing is guessed. price_applies_to flags a stored price that belongs to the vendor's platform rather than this connector. product_group names the listing's product group with its fair price per buyer tier and 90-day price-index change. reported_success stays null until 5+ distinct reporters in 90 days; after actually using a listing, call report_outcome.

Input Schema

Name	Required	Description	Default
`provider_id`	Yes	The provider_id/handle returned by search_providers or compare_providers

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "JSON result; identical to the text content block.",
+  "type": "object"
+}

Changed5 schema fields changedOct 8, 2026

removedInput schema / properties / history_days

Removed value: -{
-  "description": "Window for price_history in days (1–400, default 90).",
-  "type": "number"
-}

removedInput schema / properties / history_limit

Removed value: -{
-  "description": "Plans per page (1–50, default 10).",
-  "type": "number"
-}

removedInput schema / properties / history_offset

Removed value: -{
-  "description": "Paging offset over plans (default 0).",
-  "type": "number"
-}

removedInput schema / properties / plan

Removed value: -{
-  "description": "Optional plan name filter for price_history.",
-  "type": "string"
-}

removedInput schema / properties / price_history

Removed value: -{
-  "description": "Optional (1.17.0): include this provider's dated plan prices from Agentery's stored observations — periods at one published price, changes, coverage gaps, promotion/anomaly flags. Dates are observation dates, not necessarily when the vendor changed the price; prices stay in their original currency.",
-  "type": "boolean"
-}

Changed5 schema fields changedOct 3, 2026

addedInput schema / properties / history_days

Added value: +{
+  "description": "Window for price_history in days (1–400, default 90).",
+  "type": "number"
+}

addedInput schema / properties / history_limit

Added value: +{
+  "description": "Plans per page (1–50, default 10).",
+  "type": "number"
+}

addedInput schema / properties / history_offset

Added value: +{
+  "description": "Paging offset over plans (default 0).",
+  "type": "number"
+}

addedInput schema / properties / plan

Added value: +{
+  "description": "Optional plan name filter for price_history.",
+  "type": "string"
+}

addedInput schema / properties / price_history

Added value: +{
+  "description": "Optional (1.17.0): include this provider's dated plan prices from Agentery's stored observations — periods at one published price, changes, coverage gaps, promotion/anomaly flags. Dates are observation dates, not necessarily when the vendor changed the price; prices stay in their original currency.",
+  "type": "boolean"
+}

Changed1 schema field changedAug 1, 2026

changedInput schema / properties / provider_id / description

Previous value: -"The provider_id/handle returned by search_agents or compare_agents"New value: +"The provider_id/handle returned by search_providers or compare_providers"

AddedAug 1, 2026

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this read-only, non-destructive and closed-world, and the description goes well beyond them: fields are null when the vendor publishes nothing and nothing is guessed, price_applies_to flags a stored price belonging to the vendor's platform rather than this connector, and reported_success stays null until 5+ distinct reporters in 90 days. These are exactly the data-quality caveats an agent needs before quoting a value to a user.

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?

It is front-loaded with the usage trigger before the field inventory, and every clause carries information (null policy, price_applies_to, the 5-reporter threshold). It is still a dense single block that spills return-field detail which partly duplicates the existing output schema, keeping it just shy of a 5.

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?

An output schema exists, yet the description usefully adds semantics the schema cannot convey: what nulls mean, why price_applies_to exists, and the threshold behind reported_success. Combined with full schema coverage and clear annotations, an agent has enough to call and interpret this tool; the only real gap is disambiguation from get_provider.

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?

With a single parameter at 100% schema coverage, the schema already explains that provider_id/handle comes from search_providers or compare_providers. The description only reinforces that this identifies 'one specific listing' and adds no format or syntax detail, so the baseline of 3 applies.

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?

States a concrete verb and resource: check one specific listing (plans, prices, integrations, deployment, licence, liveness, connection paths). That is far more specific than the title. It does not, however, distinguish itself from the sibling get_provider, which by name appears to fetch the same entity, so the agent is left to guess which listing-fetch tool to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use to check one specific listing before recommending or connecting it' gives a clear trigger condition, and 'after actually using a listing, call report_outcome' explicitly hands off to the correct sibling. What is missing is guidance on when to prefer get_provider or compare_providers instead, so the alternatives are only partially covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Agentery tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?