{ "authentication": { "credentials": "https://infoblox.scalekit.com/resources/res_121813362488116511/oauth/token", "schemes": [ "oauth2" ] }, "capabilities": { "extendedAgentCard": false, "pushNotifications": false, "streaming": false }, "defaultInputModes": [ "text/plain" ], "defaultOutputModes": [ "text/plain" ], "description": "Answers questions about Infoblox DDI \u2014 DNS, DHCP, and IP address management \u2014 in plain language. Describe a symptom or a goal; the agent investigates and returns a conclusion together with the evidence behind it. You never need to know Infoblox tool names or terminology. Send your own DDI access token as `Authorization: Bearer ` \u2014 that one placement is all the agent needs, and it is the credential every DDI operation runs under, so the work is authorized and audited against your tenant. The agent holds no DDI credential of its own.", "name": "Infoblox DDI Agent", "preferredTransport": "JSONRPC", "protocolVersion": "0.3", "provider": { "organization": "Infoblox", "url": "https://www.infoblox.com" }, "securityRequirements": [ { "schemes": { "ddi_oauth2": { "list": [ "mcp:tools:read" ] } } } ], "securitySchemes": { "ddi_oauth2": { "oauth2SecurityScheme": { "description": "Authenticate with your own Infoblox DDI machine-to-machine credential using the OAuth 2.0 client-credentials grant. One credential, one placement: send `Authorization: Bearer ` with every request. The hosting runtime's authorizer validates it to admit the call and forwards it to the agent, which uses that same token \u2014 and no other identity \u2014 for the DDI work. Do not put the token in the message body: `params.message.metadata.ddi_token` is still read as a deprecated fallback for callers integrated before the header was forwarded, but a bearer in the body travels into task history, client-side logs, and traces. Request the token with `audience=https://mcp.highvelocitynetworking.com/mcp`. The token you send is forwarded unchanged to the Infoblox DDI MCP, so every operation is performed as you and audited against your tenant.", "flows": { "clientCredentials": { "scopes": { "mcp:tools:read": "Read DDI state. Required on every request \u2014 a credential without it cannot reach this agent at all.", "mcp:tools:write": "Create hosts and DNS records, and flush resolver cache. Required only for the dns-provisioning skill and for cache flushes; everything else works read-only." }, "tokenUrl": "https://infoblox.scalekit.com/resources/res_121813362488116511/oauth/token" } }, "oauth2MetadataUrl": "https://infoblox.scalekit.com/.well-known/openid-configuration" } } }, "signatures": [ { "protected": "eyJhbGciOiJFUzI1NiIsImprdSI6Imh0dHBzOi8vZGRpLWFnZW50LWVkZ2UuYWkuaW5mb2Jsb3guY29tLy53ZWxsLWtub3duL2Rucy1haWQtandrcy5qc29uIiwia2lkIjoiZGRpLWFnZW50LTIwMjYtMDgiLCJ0eXAiOiJKT1NFIn0", "signature": "E2CscRei4zAC1DGI3BQbYHzovbMt6V4B-YGLieW0lE29ho5Bk31FnqFfBtL-pPGZfomajoeJtTVQzEIje-S9Aw" } ], "skills": [ { "description": "Diagnose why a name is not resolving, why an IP address appears to be in conflict, or whether DDI infrastructure is healthy. Describe the symptom in plain language; you do not need to know Infoblox terminology.", "examples": [ "app.corp.example stopped resolving about an hour ago \u2014 what changed?", "Two machines seem to be answering for the same address. Which one owns it?", "Is the DDI platform healthy right now, or is the problem on my side?" ], "id": "dns-diagnostics", "name": "DNS and infrastructure diagnostics", "securityRequirements": [ { "schemes": { "ddi_oauth2": { "list": [ "mcp:tools:read" ] } } } ], "tags": [ "dns", "diagnostics", "troubleshooting", "health" ], "x-scopes": { "optional": [ "mcp:tools:write" ], "required": [ "mcp:tools:read" ] } }, { "description": "Answer questions about IP address space: what networks exist, how utilised they are, and where a given address or host lives. Read-only \u2014 this skill reports on address space but does not allocate from it.", "examples": [ "How much room is left in the network that 10.20.30.0/24 belongs to?", "Which networks exist in our production address space?", "Where does 192.0.2.45 live, and what is using it?" ], "id": "ipam-discovery", "name": "IP address space discovery", "securityRequirements": [ { "schemes": { "ddi_oauth2": { "list": [ "mcp:tools:read" ] } } } ], "tags": [ "ipam", "discovery", "networks", "utilisation" ], "x-scopes": { "optional": [], "required": [ "mcp:tools:read" ] } }, { "description": "Create hosts and their DNS records as part of standing up a service. Creation only \u2014 modifying or deleting existing records is outside this agent's authority; call the DDI MCP directly for that.", "examples": [ "Stand up a host called billing-api-3 at 10.20.30.44 with an A record.", "Create web-07.corp.example pointing at 10.20.31.12." ], "id": "dns-provisioning", "name": "Host and DNS record provisioning", "securityRequirements": [ { "schemes": { "ddi_oauth2": { "list": [ "mcp:tools:read", "mcp:tools:write" ] } } } ], "tags": [ "dns", "provisioning", "hosts", "records" ], "x-scopes": { "optional": [], "required": [ "mcp:tools:read", "mcp:tools:write" ] } }, { "description": "Assess DDI security posture and investigate a suspected threat or indicator. Assessment and investigation only \u2014 this agent reports findings but does not change security policy.", "examples": [ "Is our DNS security posture missing anything obvious?", "We saw traffic to a domain we do not recognise \u2014 what do you know about it?" ], "id": "security-assessment", "name": "Security posture assessment", "securityRequirements": [ { "schemes": { "ddi_oauth2": { "list": [ "mcp:tools:read" ] } } } ], "tags": [ "security", "posture", "threat", "investigation" ], "x-scopes": { "optional": [], "required": [ "mcp:tools:read" ] } } ], "supportedInterfaces": [ { "protocolBinding": "JSONRPC", "protocolVersion": "1.0", "url": "https://ddi-agent-edge.ai.infoblox.com/" }, { "protocolBinding": "JSONRPC", "protocolVersion": "0.3", "url": "https://ddi-agent-edge.ai.infoblox.com/" } ], "url": "https://ddi-agent-edge.ai.infoblox.com/", "version": "0.1.0", "x-delegated-credential": { "audience": "https://mcp.highvelocitynetworking.com/mcp", "capabilityCeiling": "This agent can read DDI state and create hosts and DNS records. It cannot delete, modify existing records, allocate networks, or change security policy \u2014 those are destructive-class operations in the DDI MCP and this agent never binds them, regardless of what your credential permits.", "forwarding": "The token you send in the Authorization header is sent unchanged to https://mcp.highvelocitynetworking.com/mcp on your behalf. The agent stores no credential, holds none of its own, and uses no other identity.", "grantType": "client_credentials", "issuer": "https://infoblox.scalekit.com", "onFailure": "A request with no Authorization header is rejected by the runtime's authorizer with HTTP 401. A token that is malformed, expired, or minted for the wrong audience is rejected with HTTP 403. Both are produced before the agent runs, so their bodies are NOT JSON-RPC \u2014 do not parse them as such. A credential that is admitted but cannot do the DDI work produces a task in state 'failed' whose status.message names exactly what to fix.", "placements": [ { "format": "Bearer ", "location": "http-header", "name": "Authorization", "purpose": "The only placement you need. The hosting runtime's JWT authorizer validates it to admit the request and forwards it to the agent, which sends it to the Infoblox DDI MCP so every operation runs as you, under your tenant's own authorization." }, { "deprecated": true, "format": "", "location": "a2a-message-metadata", "name": "ddi_token", "path": "params.message.metadata.ddi_token", "purpose": "Deprecated fallback, still honoured so callers built against the earlier instructions keep working. Prefer the header: a bearer token in the message body reaches task history, client-side logs, and traces, because A2A messages are routinely persisted and replayed. Send the header instead, and send nothing here." } ], "scopes": { "optional": [ "mcp:tools:write" ], "required": [ "mcp:tools:read" ] }, "summary": "One credential, one placement: send `Authorization: Bearer ` with every request. The hosting runtime's authorizer validates it to admit the call and forwards it to the agent, which uses that same token \u2014 and no other identity \u2014 for the DDI work. Do not put the token in the message body: `params.message.metadata.ddi_token` is still read as a deprecated fallback for callers integrated before the header was forwarded, but a bearer in the body travels into task history, client-side logs, and traces.", "tokenEndpoint": "https://infoblox.scalekit.com/resources/res_121813362488116511/oauth/token" } }